Tu parles de qc (quake code) ? Il me semble que ça n'a été abandonné qu'à partir de idTech 4.
Probablement. Je ne sais pas quand ça a été abandonné (ni même si ça l'a été en fait) par les auteurs, mais:
En fait il y a eu plusieurs techniques employées.
QuakeC
Quake utilisait QC effectivement, un langage dédié (et assez limité) et inspiré du C (ce n’est pas du C) qui se "compile" avec un outil associé (FTEQCC, GMQCC...). Les gros défauts sont en gros: la conception du langage possède des incongruités étonnantes (désolé, pas d’exemple là), aucune bibliothèque préexistante et réutilisable puisque c’est un langage de niche, et puisque la toolchain est elle aussi "de niche", les optimisations ne seront jamais aussi poussées qu’un compilateur comme GCC ou clang. QC est utilisé par Quake premier du nom. Les gros utilisateurs de QC aujourd’hui sont donc Xonotic, donc si vous voulez en savoir plus sur les défauts de QC, il suffit de demander sur le canal #xonotic sur FreeNode ;-). Si le QC est converti vers un autre format (.dat) et que j’ai employé le verbe "compiler" à ce sujet, en fait on considère que techniquement, le .dat lui-même est interprété. Donc le dernier défaut, c’est que c’est pas très rapide. Avec beaucoup d’ironie MinceR disait récemment à propos de Darkplace (le moteur dérivé de Quake 1 utilisé par Xonotic) que [Darkplace] can't be a piece of shit if it manages to run xonotic :>, on peut dire la même chose de QuakeC: son unique qualité aujourd’hui doit être de motoriser Xonotic. ;-)
QVM
C’est la techno utilisé par Quake III Arena, la QVM (ou Q3VM) est une machine virtuelle (spécifications) qui exécute (n’interprète pas) du code binaire. Le jeu se programme en C ANSI, gros plus par rapport au QC, cgest un langage standard et du code peut être partagé ou certaines bibliothèques existantes réutilisées si elles n’utilisent pas de spécificité trop modernes du langage. Par exemple lors de la transition de d’Unvanquished depuis la QVM (héritée de Tremulous et donc de Quake 3) vers NaCL, le même code C pouvait être compilé vers du code natif (une bibliothèque .so sous linux ou .dll sous windows pour faciliter le débugage avec GCC, être compilé en .qvm pour la machine virtuelle historique de Quake 3, ou compilé vers la machine virtuelle NaCL (voir ci-après). Le code est compilé avec un compilateur dédié (LCC qui a l’avantage d’être un vrai compilateur C standard, mais qui a l’inconvénient de ne pas bénéficier de toutes les optimisations que peuvent fournir un compilateur comme GCC ou clang, il en va de même pour les fonctionnalités : on doit se restreindre à un C aux spécifications figées. Le compilateur LCC n’est pas libre (c’est une espèce de shareware, pas très contraignant mais pas libre). Un des défauts est donc aussi le fait de devoir se farcir une toolchain non standard. Quand Unvanquished a complètement viré la QVM, 8 000 lignes en rapport à la QVM ont été virées du moteur, mais surtout, 23 000 lignes de code d’outils associés (pour compiler le code pour la QVM) ont été supprimés du dépôt.
Code natif
Méthode employée par Wolfenstein: Enemy Territory: le code est compilé vers une bibliothèque native (.so, .dll) et pas seulement pour le débogage. Ça peut faire sens pour un jeu non-multijoueur (comme Return to Castle Wolfenstein) de ne pas se prendre la tête avec la sécurité du code exécuté (il provient du CD de toute façon), mais ça pose de vrais problèmes de sécurité dans un jeu multijoueur comme Wolf:ET : le client se connecte à un serveur, télécharge un mod automatiquement, extrait la bibliothèque et l’exécute sans autre forme de procès. C’est un trou de sécurité immense impossible à combler sans se couper de la logithèque existante... L’avantage, c’est que le développeur est très libre (par exemple True Combat: Elite, un mod de Wolf:ET, est codé en C++). Un autre inconvénient, est qu’il faut donc compiler nativement le mod pour chaque architecture. Par exemple la seule versions de TC:E pour Mac est une version PowerPC, aujourd’hui c’est inutilisable. C’est aussi pour cela que si ET:Legacy fonctionne très bien en 64bit, il est conseillé d’utiliser la version 32bit car c’est la seule qui peut exécuter les mods existant.
Je suppose que les développeurs de RTCW avaient éliminés le code de la QVM pour leur jeu simple joueur parce que c’était inutile, et qu’ensuite, développant Wolf:ET sur la base de RTCW, ben c’était trop tard...
Le truc de Doom 3
En fait je ne sais pas quelle technologie est employée par Doom 3. The Dark Mod est basé sur Doom 3 donc ils réutilisent ladite techno, et ce serait intéressant de savoir. Peut-être que c’est aussi du code natif vu que c’était un jeu single user, je ne sais vraiment pas.
NaCl
Native Client, une machine virtuelle inventée par Google pour son navigateur Chrome, permettant de compiler du code C/C++ ou possiblement d’autres langages vers un code intermédiaire exécuté dans un bac à sable. Il y a deux versions, NaCl et PNaCl. NaCL (pour _Na_tive _Cl_ient) est indépendant du système d’exploitation : le même code x86 32bit tournera dans une machine Windows x86 32bit, Linux x86 32bit, Mac 32bit, mais il faut une (et une seule version) x86 64bit pour viser Mac/Linux/Windows en x86 32bit. Ainsi, puisque Unvanquished (qui utilise la machine virtuelle NaCl) est compilé et distribué pour x86 32/64bit (avec un client Linux/Mac/Windows), il "suffirait" de porter le moteur (et uniquement le moteur) vers Haiku/DargonFlyBSD/Syllable/AROS/Minix pour que le jeu tourne sur ces systèmes d’exploitation sans recompiler le code du jeu lui-même, tant que l’architecture est la même. Pour porter vers Power/ARM/MIPS, il faudrait recompiler le jeu mais une seule fois par architecture matérielle, indépendamment du Système d’exploitation.
PNaCl est une version _P_ortable d’NaCl: un seul et unique code distribuable est suffisant pour viser tous les systèmes d’exploitation et architecture. C’est en fait une version intermédiaire qui est translatée au moment de l’exécution vers l’architecture cible. Je ne crois pas qu’un jeu vidéo utilise cela aujourd’hui, il y a eu des expérimentations pour Unvanquished, mais rien eu de concluant, et pour diverses raisons, il y a peu de chance que quelqu’un perde du temps dessus.
NaCl fonctionne très bien, est très performant, permet d’être débuguée directement, permet d’utiliser des langages modernes (comme du C++) avec des compilateurs modernes (comme clang ou gcc, le code est converti depuis les fichiers objets après compilation) et de réutiliser des bibliothèques existantes. Par exemple Unvanquished réutilise la bibliothèqie C++ de rendu HTML/CSS libRocket pour son interface utilisateur. Le code du jeu est désormais entièrement en C++ comme le moteur de jeu, permettant d’écrire des bibliothèques pour des fonctions communes au moteur et au jeu lui-même.
Il est très peu probable que des efforts soient fait en direction de PNaCl. En effet, Google a abandonné NaCl pour son moteur Chrome. Cela n’a pas d’incidence directe pour le moteur Dæmon (et des jeux comme Unvanquished), car c’est comme si Dæmon était un autre navigateur qui fournit aussi une machine NaCl, mais la techno NaCl perd son plus gros contributeur, donc on sait déjà que ça ne va pas beaucoup évoluer. Il y a peu de chance que les développeurs de Dæmon aient l’envie et le courage de devenir les mainteneurs principaux de Nacl donc il est probable qu’une migration soit envisagée dans un moyen ou long terme, mais il n’y a rien d’urgent : NaCl fonctionne très bien et répond toujours au besoin.
WebAssembly
Je ne crois pas que des moteurs à la Quake utilisent déjà cette techno, mais c’est la techno d’avenir. Si Dæmon voulait migrer de NaCl vers autre chose, ce serait clairement vers WebAssembly. Comme NaCl, c’est une techno poussée par les développeurs de navigateurs web. Contrairement à NaCl, Google n’est pas seul dans la course: on trouve aussi Mozilla avec son Firefox par exemple. Google a donc en réalité abandonné NaCl pour WebAssembly, là où NaCl avait échoué à rassembler les développeurs de navigateurs sous une bannière commune, WebAssembly a réussi. WebAssembly est d’ailleurs plus un concurrent de PNaCl: un même code pour toutes les architectures et les systèmes. Pour des jeux comme Unvanquished ou Xonotic, WebAssembly ne serait pas encore vraiment prêt (il y a encore trop de limitation question multi-processus si je me souviens bien), et c’est encore trop frais trop mouillé, mais hyper prometteur, c’est le chemin à suivre.
Si la transition d’Unvanquished/Dæmon de la QVM vers NaCL avait été un énorme travail de très longue haleine, compliqué et chronophage, la transition de NaCl vers WebAssembly ne le serait pas tout autant : le gros du travail est fait. Notamment, tout le portage C++ est déjà fait. Une des choses fatiguantes avec la QVM c’était que tout code C++ qui devait être utilisé par le jeu devait être intégré au moteur uniquement en vue de fournir des interfaces pour le jeu en retour (!!!). Puisque NaCl permet le C++ directement, ces codes ont été correctement rapatriés dans le code du jeu, et des mods pourraient choisir d’autres technologies sans avoir à l’ajouter dans le moteur directement (un comble). Tout ça est déjà fait.
Le jeu Xonotic travaille à migrer depuis le moteur Darkplaces vers le moteur Dæmon. J’ai vu passer deux plans de migrations, le premier, naïf, peut-être plus rapide, mais qui serait un peu "dommage", serait de porter l’interpréteur QuakeC vers la machine NaCl. Une transition plus tard vers WebAssembly serait aisée : il faudrait en gros, intervertir les toolchains. Le gros défaut c’est que Xonotic se traînerait encore et toujours QuakeC. J’ai vu des personnes envisager cette hypothèse et peut-être même y travailler, mais je ne sais plus qui. L’autre solution serait de transpiler le code QuakeC vers du C++ et de faire le grand saut, en compilant le code C++ transpilé pour NaCl, ce qui ouvrirait la porte à plein de choses magiques et à l’écosystème C++ existant. C’est la solution sur laquelle travaille TimePath. Là encore, une transition de NaCl vers WebAssembly serait en gros une question de toolchain (une fois WebAssembly incorporé dans Dæmon, bien sûr, ce qui est une autre affaire).
Bon, l'article date de 2013, je ne peux pas accéder au site officiel pour voir l'état actuel de la chose... (déjà 4 ans...p'tin...)
Pour référence, l’article qui annonce la migration d’Unvanquished vers NaCl (et l’abandon de la QVM) est celui de l’alpha 37, en mars 2015.
Code du jeu (VM) et code du jeu (scripts)
En gros a l'origine une partie tres importante du code etait une VM (genre llvm) qui faisait tourner des binaires en pseudo-C, rien que ca (la raison derriere est tres pertinente, de memoire c'est utilise pour les cartes, pour la portabilite et la stabilite) peut faire fuir pas mal de codeurs, surtout amateurs. Me semble que cette section a ete remplacee par llvm, pour le coup, mais n'empeche qu'il faut du c++ pour scripter les cartes me semble (je previens, je n'avais pas trop creuse et ca date) ce qui ne facilite pas la tache.
En fait il y a confusion. ;-) les choses comme la QVM ou NaCL (le truc basé sur llvm auquel tu penses) ne sont pas utilisés pour les même choses. Ces choses-là sont faites pour coder le jeu lui-même, comme présenté plus haut, ça va être aussi le code qui intègre le moteur de rendu HTML si ton interface est en HTML. Le C++ est donc plus qu’indiqué. Une bonne partie du code réseau en fait partie aussi, généralement. En gros le moteur de jeu est principalement une machine virtuelle, quelques primitives réseau, une abstraction du système de fichier, le moteur de rendu, l’interprétation de la carte elle-même bien entendu, l’interprétation des shaders, le décodage des textures et des sons, ainsi que le système sonore.
Un jeu comme UrbanTerror (initialement un mod de Quake 3) est un jeu complet et n’est pas envisageable avec un simple langage de script. Il tourne surle moteur de jeu de Quake 3, mais il remplace intégralement le code du jeu de Quake 3. UrbanTerror pourrait fournir un langage de script, Quake 3 pourrait fournir un autre langage de script, ça ne bénéficierait pas vraiment de l’un à l’autre.
Pour scripter un jeu et des événements (par exemple en Lua, en JavaScript ou en Python), ce n’est pas le moteur de jeu qui fournit l’interpréteur éventuel pour ces langages, c’est le code du jeu, celui qui est programmé en QC, en C pour la QVM ou en C++ pour NaCl ou WebAssembly. Il est donc très très très intéressant de pouvoir coder son jeu en C++ pour pouvoir incorporer un interpréteur Lua, JavaScript ou Python qui existe déjà en C ou en C++ !
C’est donc au code du jeu de fournir un interpréteur pour ces choses-là. Et il est plus facile d’incorporer un interpréteur Python en C que recoder Python depuis zéro en QuakeC.
Le défaut des jeux comme Quake 3, c’est qu’il n’y avait pas grand chose de prévu pour les missions en joueur seul : le jeu de base était une suite de carte du jeu multijoueur avec des bots. Il n’y avait aussi quelques événements "programmables" (mais sans vrai langage de programmation dédié), par exemple une porte qui s’ouvre quand le joueur s’approche près d’elle (si le volume du joueur collisionne avec un volume invisible devant la porte, la porte s’ouvre), ou encore des actions liées à un impact de projectile (un joueur passe sous une presse, tu tires sur un objet à l’autre bout de lacarte, la presse écrase le joueur). À partir de là et avec d’autres fonctionnalités (plate-forme mobiles) on peut faire des choses un peu plus évoluées, comme des ascenseurs reliés à un bouton, des trains, ou des trucs bien plus complexe comme cette "preuve de concept" de Simon O'Callaghan : The Edge Of Forever qui est une mission mono joueur qui fonctionne sur un Quake 3 Arena non-modifié (c’est un puzzle, le joueur doit résoudre des énigmes pour ouvrir des portes et parcourir tout le niveau jusqu’à la fin). Mais la méthode est très archaïque. Ce n’est pas un langage de programmation écrit, les événements sont des objets que l’on connecte entre eux dans la carte elle-même, il faut donc passer par la case édition de la carte pour modifier la logique... Un langage dédié serait appréciable en effet.
Notez que tout cela ne fait pas partie du moteur de Quake 3, mais du code du jeu Quake 3. Pour bénéficier des ces fonctionnalités il ne suffit pas de baser son jeu sur id Tech 3, mais de reprendre aussi le code du jeu lui-même (qui est libre, aussi). Ainsi, ajouter un langage interprété pour améliorer cela se fait dans le code du jeu (celui qui tourne dans la VM).
On peut imaginer divers langages. Par exemple, ET:Legacy (à la fois un moteur pour Wolf:ET et un mod de Wolf:Et) fournit un interpréteur langage Lua, mais le système de bot est en Perl (Omnibot) mais pour ce dernier j’ai un doute s’il est embarqué dans le code du jeu ou dans le moteur avec une interface pour le code du jeu, (spyhawk< pourrait lever le doute).
Moteur id Tech 4 pour le "single user"
Un dernier point: si quelqu’un veux faire un jeu libre avec des missions, il serait plus prudent de commencer avec le moteur id Tech 4 (utilisé par The Dark Mod, qui contient des mécanismes en ce sens (Doom 3 était un jeu de ce type) : événements scriptés, dialogues, etc. The Dark Mod est un bon exemple de jeu basé sur un moteur libre et proposant des missions aux joueurs.
J’avoue que je ne sais pas du tout comment ça marche, mais c’est à mon avis le plus avancé. L’éditeur de niveau DarkRadiant est correctement maintenu en plus.
Après, pour des missions simples (un peu comme le jeux de SimonOC) avec des plateformes, des portes à ouvrir et des machines à manipuler, forker Unvanquished suffit, en plus avec Unvanquished charger des cartes en fonction de la réussite ou non de la carte précédente, ce qui est déjà pas mal, et scripter certains comportements de bots. Il ne s’agira pas de les voir faire quelque chose en fonction de ce que tu fais directement ni de ton avancée dans le niveau, mais il est possible de les faire découvrir le niveau tout seul pour te trouver, revenir à leur base pour guérir ou réparer des constructions ou des trucs comme ça.
Par contre faire émerger à partir de rien des bots au coin de la rue en fonction du chemin que tu suis (comme Half Life 2), faut oublier.
De même pour avoir des bots qui changent de comportement quand ils t’entendent, ou encore si tu veux manipuler des objets que tu trouves par terre et les jeter sur un ennemi ou quelque chose pour déclencher un mécanisme, dans ce cas il vaut mieux forker The Dark Mod.
(mince, j’ai écrit un journal)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 10.
Sommaire
QuakeC / QVM / NaCl toussa
En fait il y a eu plusieurs techniques employées.
QuakeC
Quake utilisait QC effectivement, un langage dédié (et assez limité) et inspiré du C (ce n’est pas du C) qui se "compile" avec un outil associé (FTEQCC, GMQCC...). Les gros défauts sont en gros: la conception du langage possède des incongruités étonnantes (désolé, pas d’exemple là), aucune bibliothèque préexistante et réutilisable puisque c’est un langage de niche, et puisque la toolchain est elle aussi "de niche", les optimisations ne seront jamais aussi poussées qu’un compilateur comme
GCCouclang. QC est utilisé par Quake premier du nom. Les gros utilisateurs de QC aujourd’hui sont donc Xonotic, donc si vous voulez en savoir plus sur les défauts de QC, il suffit de demander sur le canal #xonotic sur FreeNode ;-). Si le QC est converti vers un autre format (.dat) et que j’ai employé le verbe "compiler" à ce sujet, en fait on considère que techniquement, le.datlui-même est interprété. Donc le dernier défaut, c’est que c’est pas très rapide. Avec beaucoup d’ironie MinceR disait récemment à propos de Darkplace (le moteur dérivé de Quake 1 utilisé par Xonotic) que [Darkplace] can't be a piece of shit if it manages to run xonotic :>, on peut dire la même chose de QuakeC: son unique qualité aujourd’hui doit être de motoriser Xonotic. ;-)QVM
C’est la techno utilisé par Quake III Arena, la QVM (ou Q3VM) est une machine virtuelle (spécifications) qui exécute (n’interprète pas) du code binaire. Le jeu se programme en C ANSI, gros plus par rapport au QC, cgest un langage standard et du code peut être partagé ou certaines bibliothèques existantes réutilisées si elles n’utilisent pas de spécificité trop modernes du langage. Par exemple lors de la transition de d’Unvanquished depuis la QVM (héritée de Tremulous et donc de Quake 3) vers NaCL, le même code C pouvait être compilé vers du code natif (une bibliothèque
.sosous linux ou.dllsous windows pour faciliter le débugage avec GCC, être compilé en.qvmpour la machine virtuelle historique de Quake 3, ou compilé vers la machine virtuelle NaCL (voir ci-après). Le code est compilé avec un compilateur dédié (LCC qui a l’avantage d’être un vrai compilateur C standard, mais qui a l’inconvénient de ne pas bénéficier de toutes les optimisations que peuvent fournir un compilateur commeGCCouclang, il en va de même pour les fonctionnalités : on doit se restreindre à un C aux spécifications figées. Le compilateur LCC n’est pas libre (c’est une espèce de shareware, pas très contraignant mais pas libre). Un des défauts est donc aussi le fait de devoir se farcir une toolchain non standard. Quand Unvanquished a complètement viré la QVM, 8 000 lignes en rapport à la QVM ont été virées du moteur, mais surtout, 23 000 lignes de code d’outils associés (pour compiler le code pour la QVM) ont été supprimés du dépôt.Code natif
Méthode employée par Wolfenstein: Enemy Territory: le code est compilé vers une bibliothèque native (
.so,.dll) et pas seulement pour le débogage. Ça peut faire sens pour un jeu non-multijoueur (comme Return to Castle Wolfenstein) de ne pas se prendre la tête avec la sécurité du code exécuté (il provient du CD de toute façon), mais ça pose de vrais problèmes de sécurité dans un jeu multijoueur comme Wolf:ET : le client se connecte à un serveur, télécharge un mod automatiquement, extrait la bibliothèque et l’exécute sans autre forme de procès. C’est un trou de sécurité immense impossible à combler sans se couper de la logithèque existante... L’avantage, c’est que le développeur est très libre (par exemple True Combat: Elite, un mod de Wolf:ET, est codé en C++). Un autre inconvénient, est qu’il faut donc compiler nativement le mod pour chaque architecture. Par exemple la seule versions de TC:E pour Mac est une version PowerPC, aujourd’hui c’est inutilisable. C’est aussi pour cela que si ET:Legacy fonctionne très bien en 64bit, il est conseillé d’utiliser la version 32bit car c’est la seule qui peut exécuter les mods existant.Je suppose que les développeurs de RTCW avaient éliminés le code de la QVM pour leur jeu simple joueur parce que c’était inutile, et qu’ensuite, développant Wolf:ET sur la base de RTCW, ben c’était trop tard...
Le truc de Doom 3
En fait je ne sais pas quelle technologie est employée par Doom 3. The Dark Mod est basé sur Doom 3 donc ils réutilisent ladite techno, et ce serait intéressant de savoir. Peut-être que c’est aussi du code natif vu que c’était un jeu single user, je ne sais vraiment pas.
NaCl
Native Client, une machine virtuelle inventée par Google pour son navigateur Chrome, permettant de compiler du code C/C++ ou possiblement d’autres langages vers un code intermédiaire exécuté dans un bac à sable. Il y a deux versions, NaCl et PNaCl. NaCL (pour _Na_tive _Cl_ient) est indépendant du système d’exploitation : le même code x86 32bit tournera dans une machine Windows x86 32bit, Linux x86 32bit, Mac 32bit, mais il faut une (et une seule version) x86 64bit pour viser Mac/Linux/Windows en x86 32bit. Ainsi, puisque Unvanquished (qui utilise la machine virtuelle NaCl) est compilé et distribué pour x86 32/64bit (avec un client Linux/Mac/Windows), il "suffirait" de porter le moteur (et uniquement le moteur) vers Haiku/DargonFlyBSD/Syllable/AROS/Minix pour que le jeu tourne sur ces systèmes d’exploitation sans recompiler le code du jeu lui-même, tant que l’architecture est la même. Pour porter vers Power/ARM/MIPS, il faudrait recompiler le jeu mais une seule fois par architecture matérielle, indépendamment du Système d’exploitation.
PNaCl est une version _P_ortable d’NaCl: un seul et unique code distribuable est suffisant pour viser tous les systèmes d’exploitation et architecture. C’est en fait une version intermédiaire qui est translatée au moment de l’exécution vers l’architecture cible. Je ne crois pas qu’un jeu vidéo utilise cela aujourd’hui, il y a eu des expérimentations pour Unvanquished, mais rien eu de concluant, et pour diverses raisons, il y a peu de chance que quelqu’un perde du temps dessus.
Le moteur de jeu Dæmon (qui motorise Unvanquished) utilise NaCL.
NaCl fonctionne très bien, est très performant, permet d’être débuguée directement, permet d’utiliser des langages modernes (comme du C++) avec des compilateurs modernes (comme clang ou gcc, le code est converti depuis les fichiers objets après compilation) et de réutiliser des bibliothèques existantes. Par exemple Unvanquished réutilise la bibliothèqie C++ de rendu HTML/CSS libRocket pour son interface utilisateur. Le code du jeu est désormais entièrement en C++ comme le moteur de jeu, permettant d’écrire des bibliothèques pour des fonctions communes au moteur et au jeu lui-même.
Il est très peu probable que des efforts soient fait en direction de PNaCl. En effet, Google a abandonné NaCl pour son moteur Chrome. Cela n’a pas d’incidence directe pour le moteur Dæmon (et des jeux comme Unvanquished), car c’est comme si Dæmon était un autre navigateur qui fournit aussi une machine NaCl, mais la techno NaCl perd son plus gros contributeur, donc on sait déjà que ça ne va pas beaucoup évoluer. Il y a peu de chance que les développeurs de Dæmon aient l’envie et le courage de devenir les mainteneurs principaux de Nacl donc il est probable qu’une migration soit envisagée dans un moyen ou long terme, mais il n’y a rien d’urgent : NaCl fonctionne très bien et répond toujours au besoin.
WebAssembly
Je ne crois pas que des moteurs à la Quake utilisent déjà cette techno, mais c’est la techno d’avenir. Si Dæmon voulait migrer de NaCl vers autre chose, ce serait clairement vers WebAssembly. Comme NaCl, c’est une techno poussée par les développeurs de navigateurs web. Contrairement à NaCl, Google n’est pas seul dans la course: on trouve aussi Mozilla avec son Firefox par exemple. Google a donc en réalité abandonné NaCl pour WebAssembly, là où NaCl avait échoué à rassembler les développeurs de navigateurs sous une bannière commune, WebAssembly a réussi. WebAssembly est d’ailleurs plus un concurrent de PNaCl: un même code pour toutes les architectures et les systèmes. Pour des jeux comme Unvanquished ou Xonotic, WebAssembly ne serait pas encore vraiment prêt (il y a encore trop de limitation question multi-processus si je me souviens bien), et c’est encore trop frais trop mouillé, mais hyper prometteur, c’est le chemin à suivre.
Si la transition d’Unvanquished/Dæmon de la QVM vers NaCL avait été un énorme travail de très longue haleine, compliqué et chronophage, la transition de NaCl vers WebAssembly ne le serait pas tout autant : le gros du travail est fait. Notamment, tout le portage C++ est déjà fait. Une des choses fatiguantes avec la QVM c’était que tout code C++ qui devait être utilisé par le jeu devait être intégré au moteur uniquement en vue de fournir des interfaces pour le jeu en retour (!!!). Puisque NaCl permet le C++ directement, ces codes ont été correctement rapatriés dans le code du jeu, et des mods pourraient choisir d’autres technologies sans avoir à l’ajouter dans le moteur directement (un comble). Tout ça est déjà fait.
Le jeu Xonotic travaille à migrer depuis le moteur Darkplaces vers le moteur Dæmon. J’ai vu passer deux plans de migrations, le premier, naïf, peut-être plus rapide, mais qui serait un peu "dommage", serait de porter l’interpréteur QuakeC vers la machine NaCl. Une transition plus tard vers WebAssembly serait aisée : il faudrait en gros, intervertir les toolchains. Le gros défaut c’est que Xonotic se traînerait encore et toujours QuakeC. J’ai vu des personnes envisager cette hypothèse et peut-être même y travailler, mais je ne sais plus qui. L’autre solution serait de transpiler le code QuakeC vers du C++ et de faire le grand saut, en compilant le code C++ transpilé pour NaCl, ce qui ouvrirait la porte à plein de choses magiques et à l’écosystème C++ existant. C’est la solution sur laquelle travaille TimePath. Là encore, une transition de NaCl vers WebAssembly serait en gros une question de toolchain (une fois WebAssembly incorporé dans Dæmon, bien sûr, ce qui est une autre affaire).
Pour référence, l’article qui annonce la migration d’Unvanquished vers NaCl (et l’abandon de la QVM) est celui de l’alpha 37, en mars 2015.
Code du jeu (VM) et code du jeu (scripts)
En fait il y a confusion. ;-) les choses comme la QVM ou NaCL (le truc basé sur llvm auquel tu penses) ne sont pas utilisés pour les même choses. Ces choses-là sont faites pour coder le jeu lui-même, comme présenté plus haut, ça va être aussi le code qui intègre le moteur de rendu HTML si ton interface est en HTML. Le C++ est donc plus qu’indiqué. Une bonne partie du code réseau en fait partie aussi, généralement. En gros le moteur de jeu est principalement une machine virtuelle, quelques primitives réseau, une abstraction du système de fichier, le moteur de rendu, l’interprétation de la carte elle-même bien entendu, l’interprétation des shaders, le décodage des textures et des sons, ainsi que le système sonore.
Un jeu comme UrbanTerror (initialement un mod de Quake 3) est un jeu complet et n’est pas envisageable avec un simple langage de script. Il tourne surle moteur de jeu de Quake 3, mais il remplace intégralement le code du jeu de Quake 3. UrbanTerror pourrait fournir un langage de script, Quake 3 pourrait fournir un autre langage de script, ça ne bénéficierait pas vraiment de l’un à l’autre.
Pour scripter un jeu et des événements (par exemple en Lua, en JavaScript ou en Python), ce n’est pas le moteur de jeu qui fournit l’interpréteur éventuel pour ces langages, c’est le code du jeu, celui qui est programmé en QC, en C pour la QVM ou en C++ pour NaCl ou WebAssembly. Il est donc très très très intéressant de pouvoir coder son jeu en C++ pour pouvoir incorporer un interpréteur Lua, JavaScript ou Python qui existe déjà en C ou en C++ !
C’est donc au code du jeu de fournir un interpréteur pour ces choses-là. Et il est plus facile d’incorporer un interpréteur Python en C que recoder Python depuis zéro en QuakeC.
Le défaut des jeux comme Quake 3, c’est qu’il n’y avait pas grand chose de prévu pour les missions en joueur seul : le jeu de base était une suite de carte du jeu multijoueur avec des bots. Il n’y avait aussi quelques événements "programmables" (mais sans vrai langage de programmation dédié), par exemple une porte qui s’ouvre quand le joueur s’approche près d’elle (si le volume du joueur collisionne avec un volume invisible devant la porte, la porte s’ouvre), ou encore des actions liées à un impact de projectile (un joueur passe sous une presse, tu tires sur un objet à l’autre bout de lacarte, la presse écrase le joueur). À partir de là et avec d’autres fonctionnalités (plate-forme mobiles) on peut faire des choses un peu plus évoluées, comme des ascenseurs reliés à un bouton, des trains, ou des trucs bien plus complexe comme cette "preuve de concept" de Simon O'Callaghan : The Edge Of Forever qui est une mission mono joueur qui fonctionne sur un Quake 3 Arena non-modifié (c’est un puzzle, le joueur doit résoudre des énigmes pour ouvrir des portes et parcourir tout le niveau jusqu’à la fin). Mais la méthode est très archaïque. Ce n’est pas un langage de programmation écrit, les événements sont des objets que l’on connecte entre eux dans la carte elle-même, il faut donc passer par la case édition de la carte pour modifier la logique... Un langage dédié serait appréciable en effet.
Notez que tout cela ne fait pas partie du moteur de Quake 3, mais du code du jeu Quake 3. Pour bénéficier des ces fonctionnalités il ne suffit pas de baser son jeu sur id Tech 3, mais de reprendre aussi le code du jeu lui-même (qui est libre, aussi). Ainsi, ajouter un langage interprété pour améliorer cela se fait dans le code du jeu (celui qui tourne dans la VM).
On peut imaginer divers langages. Par exemple, ET:Legacy (à la fois un moteur pour Wolf:ET et un mod de Wolf:Et) fournit un interpréteur langage Lua, mais le système de bot est en Perl (Omnibot) mais pour ce dernier j’ai un doute s’il est embarqué dans le code du jeu ou dans le moteur avec une interface pour le code du jeu, (spyhawk< pourrait lever le doute).
Moteur id Tech 4 pour le "single user"
Un dernier point: si quelqu’un veux faire un jeu libre avec des missions, il serait plus prudent de commencer avec le moteur id Tech 4 (utilisé par The Dark Mod, qui contient des mécanismes en ce sens (Doom 3 était un jeu de ce type) : événements scriptés, dialogues, etc. The Dark Mod est un bon exemple de jeu basé sur un moteur libre et proposant des missions aux joueurs.
J’avoue que je ne sais pas du tout comment ça marche, mais c’est à mon avis le plus avancé. L’éditeur de niveau DarkRadiant est correctement maintenu en plus.
Après, pour des missions simples (un peu comme le jeux de SimonOC) avec des plateformes, des portes à ouvrir et des machines à manipuler, forker Unvanquished suffit, en plus avec Unvanquished charger des cartes en fonction de la réussite ou non de la carte précédente, ce qui est déjà pas mal, et scripter certains comportements de bots. Il ne s’agira pas de les voir faire quelque chose en fonction de ce que tu fais directement ni de ton avancée dans le niveau, mais il est possible de les faire découvrir le niveau tout seul pour te trouver, revenir à leur base pour guérir ou réparer des constructions ou des trucs comme ça.
Par contre faire émerger à partir de rien des bots au coin de la rue en fonction du chemin que tu suis (comme Half Life 2), faut oublier.
De même pour avoir des bots qui changent de comportement quand ils t’entendent, ou encore si tu veux manipuler des objets que tu trouves par terre et les jeter sur un ennemi ou quelque chose pour déclencher un mécanisme, dans ce cas il vaut mieux forker The Dark Mod.
(mince, j’ai écrit un journal)
ce commentaire est sous licence cc by 4 et précédentes