Construire (moteur de jeu) - Build (game engine)

Construire
Moteur de construction logo.png
Moteur de construction screenshot.png
Capture d'écran montrant Construire en mode 2D
Développeur(s) Ken Silverman
Première version 30 septembre 1995 ; il y a 26 ans ( 1995-09-30 )
Dépôt advsys .net /ken /buildsrc /
Successeur Construire 2
Licence Propriétaire
Site Internet advsys .net /ken /build .htm

Build est un moteur de tir à la première personne créé par Ken Silverman , auteur de Ken's Labyrinth , pour 3D Realms . Comme le moteur Doom , le moteur Build représente son monde sur une grille bidimensionnelle à l'aide de formes 2D fermées appelées secteurs, et utilise de simples objets plats appelés sprites pour remplir la géométrie du monde avec des objets.

Le moteur de construction est généralement considéré comme un moteur 2.5D puisque la géométrie du monde de base est bidimensionnelle avec un composant de hauteur supplémentaire, permettant à chaque secteur d'avoir une hauteur de plafond et une hauteur de plancher différentes. Le jeu montre que certains étages peuvent être plus bas et d'autres plus hauts ; même chose avec les plafonds (les uns par rapport aux autres). Les planchers et les plafonds peuvent s'articuler le long d'un des murs du secteur, ce qui entraîne une pente. Avec ces informations, le moteur de construction rend le monde d'une manière qui semble tridimensionnelle , contrairement aux moteurs de jeu modernes qui créent de véritables environnements 3D.

Bien que le moteur de construction ait obtenu l'essentiel de sa renommée en alimentant le jeu de tir à la première personne Duke Nukem 3D de 1996 , il a également été utilisé pour de nombreux autres jeux. Les jeux de moteur de construction "Big Three" sont généralement considérés comme Duke Nukem 3D , Shadow Warrior et Blood .

Caractéristiques techniques

Secteurs

Les secteurs sont les éléments constitutifs de la disposition d'un niveau, consistant en un contour polygonal bidimensionnel vu de dessus, les faces supérieure et inférieure du secteur étant données à des altitudes distinctes pour créer un espace tridimensionnel. Par conséquent, tous les murs sont parfaitement verticaux - tout ce qui apparaît autrement est techniquement un sol ou un plafond en pente. Le mot pièce peut être utilisé comme un substitut lâche pour faciliter la compréhension, bien qu'une pièce dans le monde du jeu puisse comprendre de nombreux secteurs et que des cieux parallaxes puissent donner l'illusion d'être à l'extérieur. Les secteurs peuvent être manipulés en temps réel ; tous leurs attributs tels que la forme, la hauteur et la pente pouvaient être modifiés "à la volée" par les jeux, contrairement au moteur Doom précédent . Cela a permis aux jeux d'avoir des environnements destructibles, comme ceux vus dans Blood . Cette technique est similaire à l'utilisation de parois de poussée dans la première Apogee Software titre Rise of the Triad qui présentait des environnements dynamiques similaires.

Les développeurs de jeux basés sur le moteur utilisaient des « sprites » (objets de jeu) réservés spéciaux, souvent appelés « effecteurs sectoriels » [ sic ], qui, lorsqu'ils recevaient des balises spéciales (des nombres avec des significations définies), permettraient au concepteur de niveaux de construire une dynamique monde; des informations d'étiquette similaires pourraient être attribuées aux murs et à la surface au sol du secteur pour donner à un secteur des caractéristiques spéciales. Par exemple, un effecteur de secteur particulier peut laisser les joueurs tomber à travers le sol s'ils marchent dessus et les téléporter dans un autre secteur ; en pratique, cela pourrait être utilisé pour créer l'effet de tomber dans un trou dans une pièce plus grande ou de créer un plan d'eau dans lequel on pourrait sauter pour explorer sous l'eau. Un secteur pourrait recevoir une étiquette qui le ferait se comporter comme un ascenseur ou un ascenseur.

Les secteurs pouvaient se chevaucher, à condition qu'ils ne puissent pas être vus en même temps (si deux secteurs qui se chevauchent étaient vus en même temps, il en résultait un effet de hall des miroirs ). Cela a permis aux concepteurs de créer, par exemple, des conduits d'air qui semblaient s'étendre sur le dessus d'une autre pièce (cependant, cela pouvait être difficile pour les concepteurs en raison du point de vue 2D utilisé pour une grande partie du processus d'édition). Cela a permis aux concepteurs de créer des mondes qui seraient physiquement impossibles (par exemple, une porte d'un petit bâtiment pourrait conduire à un réseau de pièces plus grandes que le bâtiment lui-même). Bien que tous ces éléments aient fait que les jeux utilisant le moteur semblent être en 3D, ce n'est que plus tard dans les jeux de tir à la première personne, tels que Quake , qui utilisait le moteur Quake , que le moteur a réellement stocké la géométrie du monde en tant que véritable information 3D, rendant la création d'une zone empilée sur une autre zone sur une seule carte est très faisable.

Voxels

Les versions ultérieures du moteur de construction de Ken Silverman ont permis de remplacer les tuiles d'art sélectionnées par le jeu par des objets 3D constitués de voxels . Cette fonctionnalité est apparue trop tard pour être utilisée dans Duke Nukem 3D , mais a été vue dans certains des derniers jeux de moteur de construction. Blood utilise des voxels pour les ramassages d'armes et de munitions, les power-ups et les eye-candy (comme les pierres tombales du niveau "Cradle to Grave", quelques chaises et une boule de cristal dans "Dark Carnival"). Shadow Warrior fait un usage encore plus avancé de la technologie, avec des voxels qui peuvent être placés sur les murs (tous les interrupteurs et boutons du jeu sont des voxels).

Pendant plusieurs années, Ken a travaillé sur un moteur moderne entièrement basé sur des voxels, connu sous le nom de Voxlap .

Chambre sur chambre

Une limitation du moteur de construction est que sa géométrie de niveau n'est capable de représenter qu'une seule connexion entre les secteurs pour un mur donné. Pour cette raison, une structure aussi simple qu'une étagère avec de l'espace au-dessus et au-dessous est impossible, bien que parfois des sprites ou des voxels puissent être substitués. Des bâtiments à plusieurs étages sont techniquement possibles, mais il n'est pas possible qu'un tel bâtiment contienne une fenêtre extérieure directement au-dessus ou au-dessous d'une autre fenêtre. De plus, certaines libertés devront être prises avec les escaliers, les ascenseurs et autres modes d'accès pour chaque étage.

Plusieurs jeux de moteur de construction (à savoir Shadow Warrior , Blood et Redneck Rampage ) ont contourné cela en affichant une "fenêtre" vers un autre secteur via une passe de rendu supplémentaire. Cette technique, appelée room-over-room (ROR), semble transparente au joueur. En plus d'une gamme étendue de constructions verticales, le ROR a souvent été utilisé pour donner aux plans d'eau des surfaces translucides . Le ROR n'a jamais été une caractéristique du moteur de construction lui-même, mais plutôt un "truc" créé par les développeurs de jeux. Une astuce utilisée dans Duke Nukem 3D pour contourner ce problème, comme dans le cas de ses sections sous-marines opaques, consistait simplement à transporter le joueur rapidement vers une autre région de la carte conçue pour l'imiter, similaire aux ascenseurs de Rise of the Triad .

En 2011, une fonctionnalité a été ajoutée à EDuke32 appelée true room over room (TROR), qui permet à plusieurs secteurs d'être empilés verticalement afin que le mur de chaque secteur ait sa propre connexion, permettant ainsi des structures verticalement illimitées. La différence entre ROR et TROR est que les secteurs TROR se chevauchent physiquement dans les données cartographiques et l'éditeur (permettant une création et une visualisation faciles), plutôt que d'être dessinés à partir d'emplacements séparés à l'aide de portails de vue, d'où une véritable pièce sur pièce. TROR est une fonctionnalité du port source EDuke32, pas une fonctionnalité ou une astuce de jeu.

Construire des jeux de moteur

Jeux qui sont construits directement sur le moteur de construction
Jeux basés sur le code Duke Nukem 3D
Jeux de moteur de construction inédits

Développement

Le moteur de construction était essentiellement un projet individuel pour Ken Silverman, bien qu'il ait consulté John Carmack pour obtenir des conseils au début du projet.

Publication des sources et développements ultérieurs

Le 20 juin 2000 (selon son site Web), Ken Silverman a publié le code source du moteur Build sous une licence propriétaire.

Premiers jours

La version 2.0 de Matt Saettler EDuke , un projet d'amélioration Duke Nukem 3D pour modders , a été envoyé à 3D Realms pour l' emballage peu après la sortie de la source de construction, laissant Duke Nukem 3D les bibliothèques pré-construits que 3D Realms avait utilisé l'original Duc. ( Duke Nukem 3D et EDuke étaient toujours des sources fermées à ce stade.)

Avec les bêtas privés 2.1 , Saettler a travaillé à l'intégration du code source de Silverman dans le code source de Duke, mais le projet a fait long feu avant de produire autre chose que des bêtas privés très bogués. Quelques équipes de conversion totale pour les jeux Build ont décidé de travailler directement à partir du code Build de Silverman, et une version améliorée de l'éditeur Build connue sous le nom de Mapster a également été développée.

Il a été affirmé à l'époque par beaucoup sur les forums 3D Realms qu'il serait impossible de porter Build sur un système d'exploitation multitâche, car il nécessitait un gros bloc de mémoire contigu qui ne serait pas disponible dans un environnement multitâche. Cette déclaration n'a pas résisté à un examen minutieux, car tous les systèmes d'exploitation modernes utilisent une mémoire virtuelle qui permet aux applications d'obtenir une mémoire logique contiguë sans utiliser de mémoire physique contiguë, mais la sagesse conventionnelle de l'époque était que le portage de Build sur un tel système d'exploitation était irréalisable.

Sortie des sources Duke Nukem 3D

Le 1er avril 2003, après plusieurs années d'affirmations contraires, 3D Realms a publié le code source de Duke Nukem 3D sous la licence GPL-2.0 ou ultérieure . Peu de temps après, Ryan C. Gordon et Jonathon Fowler ont tous deux créé et publié les ports sources du jeu, y compris le moteur de construction. Il était possible de bien jouer à Duke Nukem 3D sur la gamme NT de Windows (y compris Windows 2000/XP) et sur Linux et d'autres systèmes d' exploitation Unix, et l'intérêt pour les ports sources a grimpé en flèche.

port icculus.org

Ryan C. Gordon (icculus), avec l'aide d'autres personnes, a réalisé le premier port du moteur à l'aide de SDL . Le portage était d'abord vers Linux , puis vers Cygwin , et enfin vers une version native de Windows utilisant le compilateur Watcom C++ , qui était le compilateur utilisé pour la version DOS d'origine (bien qu'il ait été compilé avec Watcom C++, Build est en C simple.) Il y avait certains parlent de Matt Saettler utilisant cela pour porter EDuke sur Windows, mais rien n'en est sorti.

Port JonoF

Un deuxième portage source a été réalisé vers Windows, et plus tard vers Linux et Mac OS X, par Jonathon Fowler (JonoF). Ce port, JFDuke3D, ne prenait initialement pas en charge les jeux en réseau, bien que cela ait été ajouté plus tard dans le développement.

Polymost

La tâche de mettre à jour le moteur de construction vers un véritable moteur de rendu 3D a été assumée par Silverman lui-même. Dans les notes de publication de Polymost, il a écrit : « Lorsque 3D Realms a publié le code source Duke Nukem 3D, j'ai pensé que quelqu'un ferait un portage OpenGL ou Direct3D. Eh bien, après quelques mois, je n'ai vu aucun signe de quelqu'un travaillant sur un véritable portage de Build accéléré par le matériel, juste des gens disant que ce n'était pas possible. Finalement, j'ai réalisé que la seule façon dont cela allait se produire était que je le fasse moi-même. "

Le moteur de rendu Polymost autorisait les graphiques 3D à accélération matérielle à l'aide d' OpenGL . Il a également introduit "hightile", une fonctionnalité qui a permis de remplacer les textures originales du jeu par des remplacements haute résolution dans une variété de formats. Polymost a été utilisé dans JFBuild, JFDuke3D, JFShadowWarrior de Jonathon Fowler et les ports source dérivés de leurs bases de code.

EDuke32

La source d'EDuke 2.0 a été publiée plus tard, suivie par la source de la dernière bêta privée d' EDuke 2.1 (qui n'a jamais été publiée ). Richard Gobeille (TerminX) a fusionné la source EDuke 2.0 avec JFDuke3D pour créer EDuke32 . Un autre portage, Wineduke , basé sur le code icculus, a depuis disparu, laissant EDuke32 le seul port EDuke encore en développement.

EDuke32 prend également en charge les jeux NAM et WWII GI , car EDuke était basé sur le code de ces jeux.

Polymère

Le 1er avril 2009, un moteur de rendu OpenGL shader model 3.0 a été développé pour EDuke32, nommé Polymer pour se distinguer du Polymost de Ken Silverman . Au début, on pensait que c'était une blague de poisson d'avril, mais le moteur de rendu a ensuite été rendu public. Il permet des effets plus modernes tels que l'éclairage coloré dynamique en temps réel et la cartographie des ombres, la cartographie spéculaire et normale , et d'autres fonctionnalités basées sur les shaders en plus de la plupart des fonctionnalités ajoutées à Polymost au fil des ans. Bien que Polymer soit complètement utilisable, il est techniquement incomplet et non optimisé, et est toujours en développement. Les développeurs d'EDuke32 ont déclaré qu'une fois que Polymer aura été réécrit pour la vitesse, il supplantera complètement Polymost, car il s'agit d'un moteur de rendu supérieur et peut être rendu identique à Polymost.

Autres ports de jeu

Construire GDX
Développeur(s) Alexandre "[M210]" Makarov
Première version 12 janvier 2018 ; il y a 3 ans ( 2018-01-12 )
Version stable
1.04 / 13 septembre 2019 ; il y a 2 ans ( 2019-09-13 )
Dépôt gitlab .com /m210 /BuildEngine
Plate-forme Java
Taper Moteur de jeu
Licence Propriétaire
Site Internet m210 .duke4 .net

Le code source de Shadow Warrior a été publié le 1er avril 2005 sous la licence GPL-2.0 ou ultérieure , et JonoF en a publié un port source, JFShadowWarrior, le 2 avril 2005. Cependant, il a admis qu'il avait accès au Code source de Shadow Warrior environ une semaine avant sa sortie. Ce port a ensuite été forké par ProASM pour le port SWP.

Le projet Transfusion visait à recréer le moteur Blood in the DarkPlaces , mais en 2006, ce projet est loin d'être terminé, bien qu'il dispose d'un mode multijoueur complet ; un projet similaire est BloodCM qui recrée tous les niveaux monojoueurs créés par Monolith pour Blood au-dessus de EDuke32, ainsi que ZBlood qui porte certains actifs et niveaux Blood sur ZDoom .

Le code source de Witchaven , Witchaven II: Blood Vengeance , TekWar de William Shatner et Corridor 8: Galactic Wars ont également fait surface. Le statut juridique de ces derniers n'est cependant pas clair. Le code source complet d'une version alpha de Blood a également été divulgué et a été utilisé comme référence pour un port d' ingénierie inverse vers Java utilisant LibGDX appelé BloodGDX en mai 2017.

Cela faisait suite au précédent portage de l'auteur de TekWar publié en janvier 2016, et a été suivi par des ports pour Witchaven , Redneck Rampage , Duke Nukem 3D , Powerslave , Legends of the Seven Paladins et Shadow Warrior , désormais tous appelés collectivement BuildGDX .

Un autre port de Blood , appelé NBlood , a été publié en janvier 2019 basé sur EDuke32 et le précédent port Rednukem du créateur pour Redneck Rampage . Un port EDuke32 pour PowerSlave , appelé PCExhumed , a été publié le 21 novembre 2019.

Le port source Raze fournit divers ports de moteur de construction, notamment JFDuke3D , SWP , NBlood , Rednukem et PCExhumed , et le lie à un nouveau backend sous-jacent basé sur GZDoom .

Successeur

Après plusieurs tentatives pour concevoir un successeur à Build, Silverman a recommencé à expérimenter une telle idée en 2006. Il a utilisé ce travail - maintenant appelé Build 2 - tout en enseignant la programmation de jeux 3D aux enfants dans un camp d'été de 2007 à 2009, et le travail s'est poursuivi jusqu'en 2011, date à laquelle il s'est désintéressé du projet. Il dispose d'un système d'éclairage plus avancé, d'un rendu voxel pour les entités et de véritables espaces 3D pièce par pièce, et au moins en partie conservé la rétrocompatibilité avec la version originale. Silverman a rendu ses brouillons publics le 7 mars 2018. Le code source a été publié sous licence propriétaire le 8 juin 2019.

Les références

Liens externes