Cube Engine
Le Cube Engine est un moteur de jeu créé en 2002 par Wouter van Oortmerssen pour le jeu Cube. Ce moteur fut réutilisé pour d'autre jeux.
Description[modifier]
C'est un moteur 3D similaire, par certains de ses aspects à celui de Doom. Il y est, en effet, théoriquement impossible d'avoir un lieu au-dessus d'un autre. Dans les deux cas, cette limitation peut être contournée en utilisant des entités appelées mapmodels mais celles-ci tendent à être mal gérées par les armes.
La plupart des jeux utilisant ce moteur (peut-être tous) possèdent un éditeur de cartes intégré permettant de modifier des cartes existantes ou d'en créer de nouvelles. Ces cartes peuvent tout de suite être jouées car elles ne sont pas compilées. Techniquement ces cartes consistent en un tableau de zones carrées, appelées cubes, dotées d'une liste de propriétés prédéfinie (ce qui limite à huit les orientations possibles d'un mur) sur lequel des entités peuvent être placées.
Le nombre de types d'entités disponibles, qui est généralement de l'ordre d'une quinzaine, varie d'un jeu à l'autre et seuls trois types sont communs à tous les jeux utilisant ce moteur : les mapmodels (qui servent principalement à décorer la carte mais pas uniquement), les point d'apparition des joueurs (playerstart) et les lumières, qui servent à gérer la luminosité.
Pour les personnages et les mapmodels, des fichiers 3D sont utilisés. Si cube ne supporte, pour cela, que le format md2, d'autres jeu utilisant le même moteur supportent également d'autres format, comme le format md3 (en), qui est supporté par AssaultCube.
Développement[modifier]
La date exacte du début du développement de Cube et de son moteur est inconnu et doit se situer vers 2000. Cube est sorti fin 2001 et son développement a continué jusqu'en 2005, quand les développeurs du jeu ont décidé de geler ce développement pour se concentrer sur celui de Sauerbraten, sorti l'année précédente. Le moteur du jeu, quant à lui, a continué à être développé par des tiers.
Fichiers[modifier]
Chaque carte d'un jeu utilisant ce moteur est associée à un ou plusieurs fichiers. En fait, un seul de ces fichiers est obligatoire. Les autres sont tous optionnels
Le fichier cgz[modifier]
Ce fichier est le seul obligatoire. Sans lui, la carte n'existe pas. Il s'agit d'un fichier compressé.
C'est également le seul dont l'extension peut varier selon le jeu, même si, le plus souvent, c'est .cgz. Ainsi, dans les premières versions de Cube, c'était .cube.gz mais cela fut changé en raisons de décompressions accidentelles. De même, dans le jeu Newcube, c'est .ncm.
Son encodage, une fois décompressé, est le suivant :
Le fichier se divise en trois parties : l'entête, la liste des entités et la géométrie.
L'entête est ainsi constitué :
| nom | type | taille | description rapide | notes |
|---|---|---|---|---|
| head | char [4] | 4 octets | mot magique | Dans Cube, c'était CUBE mais, selon les jeux, on peut trouver d'autres valeur, comme ACMP, ACRM ou NC03. |
| version | int | 4 octets | numéro de version | numéro de version du format. Contrairement à ce que certains croient, il n'est pas toujours suffisant pour déterminer les détails de l'encodage. C'est, entre autres, la cause du glitch qui se produit quand une carte de pCube est chargée avec AssaultCube. |
| headersize | int | 4 octets | taille de l'entête | Généralement renseigné en y mettant le résultat de la formule sizeof(header). Il n'est pas vérifié lors du chargement de la carte. |
| sfactor | int | 4 octets | taille de la carte | Peut aller de 6 à, selon le jeu, 11 ou 12. l'étendue de cette carte est une zone carrée dont la largeur, en cubes, est de deux élevé à la puissance qu'est ce nombre. Cela, cependant, inclus un bord de deux cube de large qui est toujours solide et ne peut pas être modifié car il n'est pas sélectionnable avec l'éditeur de cartes. Ainsi, une carte de taille 6 à une largeur de 64 cubes dont 60 éditables. |
| numents | int | 4 octets | nombre d'entités | Le nombre maximum est toujours 65536. |
| maptitle | char [128] | 128 octets | titre de la carte | Titre complet de la carte, inclut souvent le pseudonyme de l'auteur. Modifiable avec la commande mapmsg, le laisser à sa valeur par défaut, est vu comme de l'amateurisme. |
| texlists | uchar [3][256] | 768 octets | index des textures | Chacun de ces trois index utilisés par l'éditeur de cartes contient exactement une occurrence de chacun de 256 octets différents possibles, généralement dans le désordre. |
| waterlevel | int | 4 octets | niveau de l'eau | hauteur de l'eau dans la carte. Existe dès la version 4 du format de cartes. |
| watercolor | uchar [4] | 4 octets | couleur de l'eau | Contrairement à cube qui utilise une texture (avec une tansparence fixe) pour représenter la surface de l'eau, AssautCube utilise une couleur unie (avec une transparence variable) pour la représenter. Existe dès les premières versions d'AssaultCube (dont les cartes avaient déjà 6 pour numéro de version). |
| maprevision | int | 4 octets | révision de la carte | Numéro de version de la carte. Ce numéro augmente à chaque fois que la carte est sauvegardée. Existe depuis la version 7 du format de cartes d'AssaultCube (utilisé à partir de la version 1.1 de ce jeu). |
| ambient | int | 4 octets | lumière ambiente | Permet d'avoir une lumière uniforme dans la carte. Existe également depuis la version 7 du format de cartes d'AssaultCube. |
| flags | int | 4 octets | groupe de drapeaux | Ajout de la version 10 du format de cartes d'AssaultCube (pour l'instant spécifique à des versions de développement). Dans cette version, il n'y a que 4 drapeaux, correspondant aux bits des positions numéro 0, 8, 9 et 10. Cela laisse supposer que le contenu de ce champ évoluera dans les versions ultérieures. |
| timestamp | int | 4 octets | heure Posix | Heure (et date) de sauvegarde la carte selon la norme Posix. Codé sur 32 bits, le méchanisme associé cessera de fonctionner correctement en 2038. L'implémentation de l'heure de sauvegarde la carte sera donc probablement modifiée ou supprimée d'ici là. C'est également un ajout de la version 10 du format de cartes d'AssaultCube. |
| reserved | int [v] | variable | champ réservé | À l'origine, ce champ faisait 64 octets (16 int) et était prévu pour de futures extensions. Finalement, dans Cube, il n'y aura qu'une extension de ce type : la hauteur de l'eau, ajoutée lors de l'implémentation de l'eau. Dans AssaultCube, il une extension de ce type dès la version 6 (la couleur de l'eau), puis deux autres dès la version 7 (numéro de révision de la carte et lumière ambiante) et la version 10 en ajoute encore deux autres (un groupe de drapeaux et l'heure de sauvegarde). Chacune de ces extensions occupe 4 octets et réduit d'autant la taille de ce champ. Le nombre remplacé ci-contre par un v peut donc, selon la version du format, être 16, 15, 14, 12 ou 10.
Afin d'éviter des problèmes de compatibilité avec des versions futures, il convient de laisser à zéro (valeur NUL) tous ces octets non utilisés. |
| mediareg | char [128] | 128 octets | pack de données | Spécifique aux versions 7 et 8 du format de cartes d'AssaultCube (versions 1.1.x du jeu). Dans les version 1.1.x d'AssaultCube, le jeu vérifiait lors de la sauvegarde de la carte si certaines données utilisées provenaient de pack de données et, si tel était le cas, les noms des pack utilisés étaient inscrits dans ce champ, séparés par des virgules. Dans ce cas, lors du chargement de la carte, un message apparaissait, disant quels pack devaient être installés pour que la carte s'affiche correctement, mais sans vérifier quels pack étaient ou non installés. Depuis AssaultCube 1.2, ce mécanisme a été abandonné au profit du téléchargement automatique, lors du chargement de la carte, de toutes les données manquantes disponibles, et ce champ n'est plus pris en compte qu'à cause du décalage qu'il induit (il n'est plus lu). |
La seconde partie est la liste des entités. Chaque entité de la carte correspond à une entrée de cette liste. Si elles représentent des choses assez variées, les entités ont, pour une même version du format, toutes la même structure et, donc,la même taille, 16 octets dans la version 10 du format de cartes d'AssaultCube, 12 octets dans les autres cas. Chaque entité est ainsi constituée :
| nom | type | taille | description rapide | notes |
|---|---|---|---|---|
| x | short | 2 octets | coordonnée x | ouest - est |
| y | short | 2 octets | coordonnée y | nord - sud |
| z | short | 2 octets | coordonnée z | Ne sert qu'à déterminer la hauteur de l'effet de particules qui représente l'entité en mode édition. Sa valeur n'affecte pas le rendu ou le fonctionnement de l'entité (sauf dans le cas de l'entité fire, qui n'existe que dans Newcube). |
| attr1 | short | 2 octets | attribut n°1 | C'est le seul attribut codé sur deux octets (sauf dans la version 10 du format d'AssaultCube). |
| type | uchar | 1 octet | type d'entité | Le numéro associé à un type d'entité dépend du couple mot magique/numéro de version du format. Ce numéro ne peut pas être 0, vu que c'est une valeur spéciale utilisée par l'éditeur de cartes. |
| attr2 | uchar | 1 octet | attribut n°2 | Entier non signé (de 0 à 255). |
| attr3 | uchar | 1 octet | attribut n°3 | Entier non signé (de 0 à 255). |
| attr4 | uchar | 1 octet | attribut n°4 | Entier non signé (de 0 à 255). |
| attr5 | short | 2 octets | attribut n°5 | Spécifique à la version 10 du format d'AssaultCube. Peut prendre les mêmes valeurs que l'attribut n°1 (entiers signés de -32768 à 32767). |
| attr6 | char | 1 octet | attribut n°6 | Spécifique à la version 10 du format d'AssaultCube. Seul attribut de type char (entier signé de -128 à 127). |
| attr7 | uchar | 1 octet | attribut n°7 | Spécifique à la version 10 du format d'AssaultCube. Entier non signé( de 0 à 255). |
La troisième et dernière partie, la géométrie, consiste en une liste d'entées de longueur variable. La longueur de chacune de ces entrées dépend de son premier octet, pour lequel il peut y avoir huit valeurs différentes possibles : les numéros des six types de cubes (de 0 à 5) du jeu et deux valeurs spéciales (254 et 255).
Les six types de cubes sont les suivantes :
- SOLID (0)
- Zone "solide", c'est-à-dire impénétrable et sans sol ni plafond. La plupart des murs allant du sol au plafond sont de ce type.
- CORNER (1)
- Mur, allant ou non du sol au plafond, à 45° de l'orientation des bords des cubes.
- FHF (2)
- Sol "heightfieldé", le sol peut ne pas être plat ou être d'une hauteur qu'un cube d'un autre type ne peut pas avoir.
- CHF (3)
- Plafond "heightfieldé", même principe mais pour le plafond.
- SPACE (4)
- Cube normal.
- SEMISOLID (5)
- Type spécial, généré par le mipmapping.
Les cubes de type solide (0) sont décrits avec des entrées de trois octets :
- type (ici 0)
- texture (valeur wtex, qui, avec les autres types de cubes, correspond à la texture du mur inférieur)
- valeur delta (pour d'éventuels cubes voisins heightfieldés)
Les autres cubes sont tous décrits avec des entrées ayant la même structure de neuf octets :
- type (ici de 1 à 5)
- hauteur de sol (de -128 à 126)
- hauteur de plafond (de -127 à 127)
- texture du mur inférieur
- texture du sol
- texture du plafond
- valeur delta
- texture du mur supérieur
- tag
Les deux valeurs spéciales sont :
- pareil sauf pour la lumière (254)
- abandonné depuis la version 3 du format de cartes mais toujours supporté par l'algorithme de chargement de cartes. Le cube correspondant à une entrée de ce type a les mêmes particularités que le précédent, sauf pour ce qui est de la lumière.
- pareil (255)
- Constitue un deuxième niveau de compression. Ce type d'entrées correspond à une série de cubes identiques. C'est le seul cas où une entrée peut correspondre à plusieurs cubes. Les cubes correspondant à une entrée de ce type ont les mêmes particularités que celui de la précédente entrée d'un autre type.
La première de ces deux valeurs correspond à des entrées de trois octets :
- type (ici 254)
- intensité de la nouvelle lumière
- un octet inutilisé (rôle d'origine inconnu; totalement inutilisé aujourd'hui)
L'autre correspond à des entrées de deux octets :
- type (ici 255)
- nombre de cubes (de 1 à 255)
Les autres fichiers[modifier]
Ces fichiers, tous optionnels, ne diffèrent du fichier cgz que par leur extension. À l'exception du ficher cfg, qui est supporté par tous les jeux utilisant ce moteur, et du fichier texte, qui n'est aucunement utilisé par le jeu, ces fichiers ne sont supportés que par certains des jeux utilisant ce moteur.
Ces fichiers se trouvent dans le même dossier que le fichier cgz, à l'exception du fichier wpt et du fichier de preview.
- Le fichier cfg
- Le contenu de ce fichier texte est, techniquement, un script en CubeScript qui est exécuté lors du chargement de la carte. Ce fichier n'est pas créé par le jeu. Il doit être créé séparément avec un éditeur de texte. Si, dans l'absolu, il est optionnel, il est nécessaire pour changer certains paramètre de la carte ou y inclure dans la carte des textures ou des mapmodels non mentionnés dans le fichier default_map_settings.cfg (dont l'emplacement varie selon le jeu), qui est toujours exécuté juste avant ce fichier.
- Ce fichier peut également comporter, en commentaires, des informations relatives à la carte, comme les droits d'auteur. Contrairement à ce qui est souvent cru, mettre ces informations dans ce fichier n'était une chose courante avec les cartes de Cube (ce n'est le cas d'aucune carte officielle de Cube), elles étaient alors plutôt mises dans un fichier séparé, généralement au format txt. Le choix de mettre ces données dans le fichier cfg à la place semble être une conséquence de l'ajout, dans AssaultCube, d'un système de téléchargement des cartes, qui ne télécharge que le fichier cgz et l'éventuel fichier cfg.
- De plus, afin d'empêcher l'exécution de scripts potentiellement malveillants, AssaultCube (et les jeux basés sur ce jeu) n’exécute que certaines commandes de ces fichiers. Les autres, au lieu de s'exécuter, causent l'affichage d'un message d'erreur.
- Le ficher texte (ou fichier txt)
- Ce fichier, qui n'est aucunement utilisé par le jeu, est parfois sans extension mais, le plus souvent, il a .txt pour extension. Son contenu est expliqué ci-dessus, dans la section sur le fichier cfg.
- Le fichier wpt
- Spécifique aux jeux utilisant des bots. Contient les waypoints utilisés par les IA de ceux-ci. L'IA des monstres, très différente de celle des bot, n'utilise pas de waypoints.
- Le fichier de sauvegarde (ou fichier bak)
- Sauvegarde de précédentes versions du fichier cgz. Ce fichier a une double extension. La première consiste en un underscore suivi d'une série de chiffres donnée par l'horloge du système et la seconde est .bak. Il peut donc y avoir plusieurs fichiers bak pour une même cartes.
- Le fichier de preview
- spécifique à AssaultCube (et aux jeux basés sur ce AssaultCube). C'est l'image qui apparait à côté du menu dans les menus listant des cartes. Il s'agit généralement d'une image au format jgeg (ce qui est le cas pour toutes les cartes officielles d'AssaultCube) mais il peut également d'une image au format png dont l'extension a été changée. L'extension du nom de ce fichier est toujours .jpg.
Performances[modifier]
Le Cube Engine a un rendu généralement fluide. Si le nombre de frames par seconde (FPS) peut descendre très bas (plus ce nombres est élevé, plus le jeu est fluide) dans certains cas, cela reste moins fréquent qu'avec le Cube 2 Engine (moteur de Sauerbraten).
Erreur Lua dans Module:Catégorisation_badges à la ligne 170 : attempt to index field 'wikibase' (a nil value).Erreur Lua dans Module:Suivi_des_biographies à la ligne 189 : attempt to index field 'wikibase' (a nil value).
Cet Article wiki "Cube Engine" est issu de Wikipedia. La liste de ses auteurs peut être visible dans ses historiques et/ou la page Edithistory:Cube Engine.
