Terminal Overload est un FPS (First Person Shooter) libre multijoueur, qui se déroule dans un univers abstrait et futuriste. C’est un successeur de [Revenge Of The Cats: Ethernet](http://ethernet.wasted.ch/), sorte de mix entre KernelPanic et Warsow avec un rendu de type filiforme qui peut rappeler Tron. Les binaires 32 bits pour Windows et GNU/Linux sont fournis ainsi que le code source à compiler.
Un financement participatif (crowdfunding) avait été lancé par l’auteur de Revenge Of The Cats: Ethernet, Michael Goldener, le 6 décembre 2013, avec pour but de libérer l’ensemble du jeu dont le moteur n’était pas entièrement libre.
Torque3D, une version moderne et libre du moteur était apparue et fut adoptée. Le but de l’appel à financement était donc de porter le jeu sur ce moteur. Le financement ayant été atteint, une divergence (fork) a été créée et la version 0.1 sortie le 1er août 2014 sous le nom de Terminal Overload.
Il utilise donc désormais le moteur Torque3D sous licence MIT (au lieu du moteur Torque Game Engine). La licence du code est la GPL v3 et les données sont sous Creative Commons Attribution 4.0 International.
Malheureusement, il n’y a plus d’activité depuis le 5 février 2016.
Y aurait‐il un repreneur dans la salle ?
Aller plus loin
- Site officiel (694 clics)
- Revenge Of The Cats: Ethernet (148 clics)
- Vidéos de jeu (327 clics)
- Du crowdfunding pour libérer Revenge of the Cats: Ethernet (107 clics)
- La fiche sur jeuxlibres.net (123 clics)
# Le principe est cool
Posté par karchnu . Évalué à 1.
L'idée de changer un perso en un chat qu'il faut toucher est plutôt sympa, ça fait varier le gameplay.
Par contre gros bémol selon moi, les graphismes. De nos jours, même pour un jeu libre, ça fait cheap. Si un repreneur pouvait se charger de ça… je lui envoie des cœurs ♥ !
# pas de FPS libre mono-joueur?
Posté par wismerhill . Évalué à 5.
Encore un FPS pour faire du multi-joueur.
N'y a-t-il donc personne dans le libre qui ait envie de réaliser des compagnes solo?
J'ai beaucoup joué aux FPS, mais le multi-joueur ne m'a jamais beaucoup attiré (trop répétitif).
Mon préféré reste halflife premier du nom, le mode solo original était très original avec plein de styles différents et des séquences scénarisées bien pensées.
Il y a quelque années j'ai fait une "rechute", j'ai d'abord refait toute la compagne originale de halflife et les extensions officielles, puis je suis allé voir dans les mods solo disponible en ligne. Il y en a plein qui avaient été développé entre temps, dont certains de très grande qualité (égale, voir supérieure, au jeu original). Et tout ces mods avaient été développés par des amateurs, et mis à disposition gratuitement.
Pourquoi ne voit-on pas ça avec des FPS libres?
Est-ce qu'ils manquent d'outils de développement de niveau intermédiaire, genre éditeurs de niveaux avec possibilité de scriptage, destinés à des non programmeurs?
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Il y a les gens qui développent freedoom 1 et 2, blasphemer et zauberer (le dernier est trop embryonnaire pour être jouable).
Il y a aussi des gens (parmi lesquels le dev principal d'openarena) qui avaient tenté à une époque de faire un quake libre. Ça n'était pas allé très loin.
Il y avait aussi le projet blobwars 2, de parallel realities, maintenant abandonné.
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 10.
De manière générale la communauté du jeu libre est minuscule, donc des genres de jeu qui n'ont aucun représentant (un minimum abouti) il y en a des tonnes.
Après pour ta question en particulier, je dirai qu'un FPS en multi, c'est le genre de jeu vraiment très adapté à du développement itératif communautaire. Une (petite) map, une arme, une skin de joueur et tu peux déjà jouer ; ensuite les gens vont pouvoir ajouter des maps/armes/skin au fur et à mesure. Le jeu s'enrichit mais il est intéressant à chaque étape ; évidemment il faut de l'équilibrage, ce n'est pas trivial non plus, mais dans l'ensemble ça marche bien. Et détail important, les gens qui créent le jeu peuvent s'amuser au même titre que les "simples" joueurs.
Alors qu'au contraire, un FPS solo (on peut élargir le raisonnement à tout jeu centré sur l'histoire), il va falloir une map très grande (sûrement plusieurs en fait), des ennemis différents, des PNJ & beaucoup d'assets de manière générale, avant de pouvoir offrir quelque chose d'amusant au joueur. Pour une expérience aussi dense que Half-Life, il va falloir, pour chaque minute de joueur, des jours de travail pour les créateurs. Et détail important, les créateurs ne peuvent pas vraiment apprécier leur œuvre comme les simples joueurs (vu qu'il connaissent l'histoire, ce qu'il faut faire etc…).
Du coup, ce genre de jeu est vraiment plus adapté à un développement par une entreprise, qui propose une expérience à "consommer" (ce n'est pas un gros mot) en échange d'argent. Ce qui n'exclut pas que ce soit libre dans l'absolu évidemment.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 4.
D'une manière générale on peut observer que la grande majorité des jeux libres sont conçus en tant qu'œuvres ludiques et peu en tant qu'œuvre artistique. On a même des projets qui se félicitent d'avoir créé un jeu fun et populaire sans aucune cohérence artistique.
Ce type de jeu est effectivement très adapté au mode de développement "bazar". Ce n'est que quand le jeu commence à se complexifier et que la communauté commence vraiment à grossir qu'il faut un comité de décision chargé de faire le tri entre ce qu'on accepte et ce qu'on refuse en terme de gameplay. Mais côté art, quelle que soit la cohérence des assets, les joueurs continueront à jouer. Et la communauté de joueurs apporte bien plus de valeur au jeu que la qualité artistique.
Pour les jeux solo, j'ai plus l'impression qu'il faut assez vite mettre en place un développement "cathédrale". Il faut au moins un directeur artistique qui ait une idée très précise de ce que le joueur doit ressentir, et de comment le jeu doit véhiculer ces impressions et ces émotions. Ça sous-entend 1) un travail de très longue haleine, parce qu'il faut refuser beaucoup de contributions, refaire certains trucs, etc. 2) des gens qui restent impliqués dans le projet sur une très longue période. Ou alors, il faut réussir à définir la direction artistique dans un document exhaustif et précis qui résistera aux années : c'est de la paperasse, personne n'aime la paperasse.
Parmi les projets que j'ai cités, freedoom et blasphemer sont probablement les plus aboutis, mais même eux sont plus des "challenges ludiques" que des œuvres d'art. Sur freedoom on voit des assets changer d'une version à l'autre, parfois sans différence de qualité entre le nouveau et l'ancien. Et aucun développeur de freedoom n'est capable de donner une définition artistique de freedoom. Blobwars 2 était probablement parti pour être plus cohérent artistiquement, justement parce que développé par un petit groupe fermé (Parallel Realities). Quant à OpenQuartz, ça aurait sûrement donné quelque chose d'équivalent à freedoom.
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Un bon exemple est le vieux principe des MUD : pas d'assets artistiques, il est relativement facile de contribuer des donjons ou de rajouter des fonctionnalités dans le code. Par contre la cohérence globale du monde en termes d'histoire, le dosage de la difficulté et les interférences possibles entre zones ne peuvent être réglées/tranchées que par un comité de décision. La communauté de joueurs fait/faisait ici la valeur du jeu. Les versions « modernes » avec images 2 ou 3D/animations/etc. ont en plus à régler la question des assets artistiques.
Pour la scénarisation solo, sauf à avoir un système hyper-générique non lassant (*) qui permette de jouer et rejouer (pour les contributeurs actifs du projet aussi), c'est compliqué d'avoir itérativement des retours, sauf à avoir une communauté énorme. Et les soucis d'assets artistiques et d'équilibrage sont toujours à traiter.
(*) ça semble plus ou moins du niveau de difficulté du générateur illimité de scénarios de films/bouquins/histoires ou du générateur générique de code pour obtenir n'importe quelle application ou du solveur mathématique générique
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 5.
Il y a aussi la satisfaction personnelle : développer un jeu solo donne l'impression de s'investir énormément pour quelque chose d'éphémère, auquel les gens joueront une fois ou deux puis passeront à autre chose, alors que développer un jeu multi donne l'impression de s'investir moins pour un résultat plus durable. Et dans les deux cas on doit le maintenir.
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par wismerhill . Évalué à 2.
Pourtant, j'en reviens à mon message initial, il y a de nombreux mods solo créés par des particuliers, qui sont parfois de grande qualité (dans ce cas ce sera fait par une petite équipe plutôt qu'une personne seule), et sont disponibles gratuitement (volontairement, pas par piratage).
Donc il y a des gens qui ont envie de faire ce genre de chose, que ce soit par passion, comme un défi, ou pour se faire une référence pour ensuite en faire son métier.
Donc je me demande, est-ce qu'aucun de ces FPS libres (à part les clones de doom) ne met à disposition l'infrastructure pour faire des campagnes solo?
Parce que forcément, s'ils ne font que du multi ça ne va pas attirer les gens qui seraient susceptibles de créer des campagnes solo.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Désolé je comprends bien que tu voudrais connaître l'état des outils libres permettant d'écrire des campagnes solo de FPS (par rapport à ce qu'on trouve du côté proprio) ; la question est intéressante mais je n'ai pas la réponse (si quelqu'un a la réponse, qu'il n'hésite pas). Mais en effet il est très possible que le libre soit en retard de ce côté (pas étonnant vu que ce genre d'outils est écrit à la base par des entreprises pour leurs propres besoins de campagnes solo).
Il arrive effectivement que des gens tout seul arrivent à faire des mods (voire des jeux complets) , donc c'est techniquement possible, je n'ai pas dit le contraire. Je faisais juste remarquer qu'il agit quand même d'un phénomène assez rare (la plupart des joueurs vont juste consommer), et que ramené à la population des joueurs de jeux proprios ça ne représente qu'un très faible pourcentage. Si on applique le même pourcentage à la communauté des joueurs libres (infiniment plus petite), alors ce n'est pas étonnant qu'on arrive à environ 0 ; en gros il s'agit peut-être de l'affaire d'une seule personne motivée (ou pas).
Pour faire un parallèle, on a tous les outils pour faire de la BD libre (et encore, dans l'absolu on est pas obligé de n'utiliser que des logiciels libres pour faire une BD libre). Pourtant si tu peux trouver des tas de dessinateurs en herbe qui mettent gratuitement en ligne des strips, la BD libre ça n'existe pas vraiment (sauf l'exception Pepper & Carrot). J'imagine que beaucoup de ces créateurs envisagent le jour où ils pourraient être remarqués et édités de manière classique ; et quand bien même ils connaîtraient les licences libres (ce qui n'est pas gagné), je pense qu'ils préfèrent garder le contrôle "au cas où" (et c'est triste). Du coup, autant je suis le premier à être ravi de l'existence d'outils comme Godot (qui permettent de faire des jeux plus facilement, parfois sans vraiment coder), autant il y a encore pas mal de chemin à parcourir au niveau des mentalités, car ces outils ne garantissent malheureusement pas l'arrivée de nombreuses œuvres abouties.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
À propos des gens qui arrive à faire des mods/jeux en étant seuls:
cela n'enlève rien au travail parfois titanesque de ces personnes, mais souvent le principe des mods consiste à réutiliser les assets du jeu solo de base (et donc on revient à mon premier commentaire sur le fait de les créer lesdits assets dans le cas des jeux libres). On a aussi les fan-games qui réutilisent de manières illicites des assets d'un jeu ; ce qui pour un jeu gratuit ne me choque pas plus que ça (quand il s'agit de toute évidence d'un hommage), mais si on veut faire les choses proprement, un jeu libre ne pourrait évidemment pas se le permettre.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Il s'agit sûrement d'une question de motivation. Le code est là : idTech 1, idTech 2-0, idTech 2, idTech 3, idTech 4. Ce qui a été possible avec freedoom et blasphemer est sûrement possible avec les autres jeux d'id.
Après pour faire un mode solo basé sur des jeux multi (openarena, xonotic, redeclipse) là il faut peut-être écrire un peu de code d'IA et d'UI supplémentaire.
Mais le gros du boulot est vraiment sur l'art, si tu veux faire un FPS libre solo, pour démarrer il te faut :
1) un bon concept
2) deux-trois beaux modèles de maychants avec des belles textures pour appâter le contributeur
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 3.
Le code est la, oui… sauf que je deconseillerais perso tres fortement de partir sur le code des vieux quake: ok ca marche, mais ce que j'en ai vu (une version evoluee, celle d'unvanquished il y a quelques annees) je dirai poliment que la dette technique est immense.
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.
Ecrire une campagne solo, meme en terme de code, c'est autrement plus complique que le multi… deja faut coder des ia qui tiennent la route (pas faibles et pas cheatees) point faible de la plupart des fps libres auxquels je me suis essaye.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Tu parles de qc (quake code) ? Il me semble que ça n'a été abandonné qu'à partir de idTech 4.
Le code des IA n'a pas été libéré avec le code des moteurs idTech ? Est-ce que les IA de freedoom, d'OA et de Nexuiz ont été codées par les devs des différents projets ?
Tu penses quoi des IA des monstres de freedoom ?
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Probablement. Je ne sais pas quand ça a été abandonné (ni même si ça l'a été en fait) par les auteurs, mais:
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…)
Je suppose que si, mais une IA pour jouer solo ou une IA pour multi, je doute fort que ça agisse de la même façon.
Dans une campagne solo, je pense que les IA doivent être beaucoup plus scriptées, pour permettre de suivre un scénario: par exemple le monstre de DN3D qui attendait assis dans les chiottes ou les chiens de medal of honor assaut allié qui te fonçaient dessus direct quand l'alarme sonnait (il y a plein d'autres exemples). Je dirai qu'a vue de nez c'est plus simple, mais il y a moins de code existant, vu que tous les efforts ont tendance à aller vers le multi.
Je ne connais pas vraiment freedoom, j'ai toujours eu ce sentiment d'être perdu quand j'ai tenté de le lancer. Au final, ça ressemble à un jeu de niveaux jetés ensemble dans une campagne de façon plus ou moins aléatoire.
Pour le côté du code, c'est sûrement très différent oui, même si je n'ai aucune preuve: déjà les IAs de doom ne vont pas nécessairement bouger tant qu'elles ne recoivent aucun évènement: dans nexuiz, si, et heureusement (ça fait longtemps que je n'y ai pas joué à celui la tiens), et même sans ça, je ne crois pas que les moteurs de quake et de doom soient compatibles?
En tout cas, je trouve les IAs de nexuiz franchement bof, de mémoire (plusieurs années que je n'y ai pas joué) le «mode solo» n'est pas vraiment difficile.
Pas d'avis, je connais pas assez freedoom.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Dans mes souvenirs il y avait un zombie dans les chiottes dans freedoom 0.7, et deux trois autres triggers "complexes" mais la plupart du temps les monstres réagissent de façon très simple (quand ils te voient ou quand ils se font tirer dessus).
Mais même les triggers complexes je ne pense pas que les devs de freedoom aient eu à les coder (ce sont des éléments que tu ajoutes dans les maps, style une ligne à traverser, ou une zone sur laquelle marcher).
Je pense qu'à partir de la 0.11 il y a beaucoup plus de cohérence dans la façon dont les maps sont conçues. Mais il a fallu 14 ans pour en arriver là, et c'est à mon avis dû à l'absence de direction artistique claire (cf mon commentaire plus haut).
Non mais le projet openquartz avait pour but de faire une campagne solo sur le moteur de quake. Et il y avait des bots stupides, un peu comme freedoom. Le jeu comprenait un seul niveau, puis le développeur a arrêté, sûrement pour se concentrer sur OpenArena.
Bah le CTF sur eggandbacon j'ai du mal. En instagib aussi les IA sont pas mal. Après c'est vrai que sur Nexuiz et OA les niveaux d'IA les plus difficiles consistent juste à leur donner 99% de précision. J'aimerais bien voir un jeu libre où les IA d'arène ont un comportement plus "humain".
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . É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
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Je sais pas si j'ai tout compris pour QVM. Je doute fort que les développeurs d'OA utilisent un compilateur non-libre, ils font comment alors ?
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
y a peut-être des alternatives libres aussi, c'est pas impossible à ré-implémenter !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par BAud (site web personnel) . Évalué à 2.
faudrait demander à sago : visiblement, il bosse encore dessus https://github.com/OpenArena/gamecode
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 23 août 2017 à 21:21.
https://github.com/OpenArena/gamecode/blob/master/code/tools/lcc/COPYRIGHT
https://github.com/ioquake/ioq3/blob/master/code/tools/lcc/COPYRIGHT
https://github.com/Unvanquished/Unvanquished/blob/v0.36.0/src/tools/lcc/COPYRIGHT
Bref, c’est du Fair-Use-NC-ND.
Bouh, OpenArena sapusaypalibre ! :o Maintenant tu as une bonne raison de ne plus jouer à OpenArena, en plus d’être môche, saypalibre ! :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Ben si c'est libre, c'est juste que ça utilise un langage et un environnement de build propriétaires :)
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Le langage c’est du C ANSI a priori, donc ça va encore, mais oui il n’est pas possible de produire le jeu complet sans un outil propriétaire.
Il est peut-être possible de compiler le même code en shared lib (au lieu d’un binaire pour la Q3VM), mais dans ce cas, adieu le jeu en ligne.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Mais du coup je me demande : comment ça se fait que Debian laisse passer ça ? Parce que Debian produit le paquet binaire à partir du paquet source, et ils acceptent des trucs non-libres dans le paquet source ?
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Je me réponds à moi-même :
https://sources.debian.net/src/openarena/0.8.8-19/debian/README.source/
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Donc ils font bien ce que je supposais… Mais ça signifie que l’environnement d’exécution du client n’est pas “pur” par rapport au serveur (le serveur ne peut pas vérifier que le client utilise un code de connu, ça pourrait aussi être un aimbot ou autre triche), comment font-ils pour le jeu en ligne ? Il n’y a pas de vérification du tout ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
J'ai envie de dire qu'il n'y a pas de vérification du tout, vu le nombre de tricheurs qu'on peut trouver sur les serveurs où il n'y a pas de ban, mais maintenant que j'y pense il me semble avoir constaté une fois qu'avec le binaire officiel j'avais beaucoup plus de serveurs dans la liste du lobby qu'avec la version debian, du coup je sais pas.
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Bah si tu te contentes d'utiliser le binaire en tant qu'utilisateur tu es libre, mais si tu compiles non.
Du coup ça veut dire qu'en clonant le repo d'OA3 j'ai mis des outils non-libres sur ma machine :(
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Si je suis ton raisonnement, un outil open source sous windows qui fait appel aux lib de windows n'est pas libre?
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Oui, et c’est un raisonnement assez partagé en fait.
C’est pour cela que de nombreux projets libres font l’effort de ne pas compiler leur paquets windows avec le compilateur de microsoft, parce que dans ce cas le binaire produit ne serait pas un logiciel libre.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Moi qui pensais qu'il y avait consensus sur le fait qu'un logiciel libre en est un qui respecte les 4 libertés…
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
La question est intéressante.
Je trouve qu'à l'échelle d'un logiciel, raisonner la liberté non pas de façon binaire (libre ou pas libre) mais de façon "analogique" peut être pertinent.
J'aurai tendance personnellement à trouver que (je rappelle que les 2 sont similaires en tant que jeu et entièrement sous licence libre) l'apport du 2ème au libre est nettement moindre ; juste dire qu'ils sont libres est un peu réducteur.
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Je suis globalement d'accord, mais dans ce cas, on peut pratiquement considérer qu'un logiciel non libre puisse avoir un apport au libre plus important qu'une alternative libre…
Supposons une fonction qui serait réalisée traditionnellement par des outils dont le format est mal documenté quasi hermétique, qu'ils soient libres ou non.
Supposons ensuite un logiciel fermé qui, lui, documente de façon claire son format et que le format en question soit, lui, libre.
Le logiciel libre au format dégueulasse et mal documenté, avec un code de qualité merdique voire obfusqué apporte-t-il plus au libre que le logiciel fermé qui documente son format de sortie de façon claire et l'ait libéré?
Je pense que non, et pourtant, il n'est pas libre.
Dans l'absolu, le puriste libriste préfèrera le logiciel libre, qui n'offre que des libertés théoriques, tandis que le logiciel proprio lui, offrira en pratique un moyen simple d'écrire une alternative (utilisant son expertise technique, son niveau d'optimisation ou d'autres techniques de qualité de logiciel pour garder sans l'enfermer son public).
J'imagine que l'on peut distinguer 2 types de libre: l'idéaliste et le pragmatique.
Tu vas sûrement me dire que le logiciel libre dont je parle n'existe pas… c'est probable, du moins, pas de façon volontaire par ses auteurs, mais qui n'a jamais lu de code libre impossible à forker tellement c'est sale?
Pour ce qui est du logiciel propriétaire, c'est aussi purement théorique, mais je me souviens de la raison qui m'a fait abandonner Firefox pour Opera 8: un meilleur support du standard.
La frontière entre le libre et le non libre est claire: un logiciel qui respecte les 4 libertés est libre, point.
La ou le problème existe, c'est si on commence à considérer qu'il y a un esprit libriste. Ça, ça n'existe pas ou c'est tellement flou qu'il en existe une quasi infinité.
Si je prend ton exemple de code libre en flash, peut-être bien que si, il apporte une vraie plus-value au libre, par exemple s'il s'agissait d'un logiciel de conception d'une qualité équivalente à solidworks, katia ou autocad.
Je pense sincèrement que la technologie utilisée n'est pas le seul critère à prendre en compte du coup. Mais ça dépend des sensibilités j'imagine.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
L'utilisateur qui enregistre ses données dans un format fermé , fût-ce avec un logiciel libre, voit sa liberté limitée, car il est dépendant d'une implémentation donnée de ce format. En fait, il est libre tant qu'il considère cette implémentation comme respectueuse de sa liberté.
Si il partage ces données dans ce format fermé, c'est encore pire, parce qu'il met en danger la liberté des autres utilisateurs en les poussant à utiliser un logiciel dont ils ne veulent pas forcément.
À l'opposé, un utilisateur qui s'assure que toutes les données qu'il partage sont enregistrées dans un format ouvert, fût-ce avec des logiciels non-libres, ne met pas en danger la liberté des autres utilisateurs, puisque ceux-ci restent libres d'utiliser l'implémentation de leur choix.
Le logiciel libre n'est pas une question d'"esprit libriste". C'est une réflexion dont la question de départ est simplement : "l'utilisateur est-il libre ?".
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
On s'éloigne encore un peu (mais tant pis c'est amusant), mais oui on peut aller jusque là si on est taquin. Un 2000ème CMS en PHP/MySQL ne sera sûrement pas une contribution majeure au libre (et ce n'est pas grave, ses créateurs font ce qu'ils veulent) ; à côté de ça, l'IHM d'iOS a beaucoup inspiré celle d'Android par exemple (ou bien 0AD est clairement inspiré d'Age of Empires etc…). Évidemment, je ne dirai pas qu'Apple, en ce qui concerne iOS en tout cas, a fait une contribution au libre, ou que c'est cool que iOS soit propriétaire. Juste qu'à leur manière ils ont apporté quelque chose à l'humanité (mais bien sûr ça serait tellllleeement mieux si c'était libre, snif).
Je n'ai jamais dit que le logiciel en Flash n'avait aucune plus-value. Dans mon exemple il y aurait aussi un solidworks-like libre en C++ (équivalent à l'autre en Flash), qui aurait une plus grande plus-value. Pour mesurer cette différence de plus-value libre en fonction des dépendances/technos, c'est important dans mon exemple de ne faire varier qu'un seul paramètre (la techno) ; parce que sinon comparer un solidworks en flash et un tetris en C++, n'a pas vraiment de sens.
Toutafé. Je suis le premier a expliquer aux gens que non, open source c'est pas juste que le code est visible ; ou que non CC-NC/ND c'est pas du tout libre.
Du coup OpenArena n'est pas libre (il se balade avec du code non libre, point), mais la version expurgée de Debian l'est.
Je ne veux surtout pas remettre en question la définition de libre ; déjà rien qu'avec la définition commune tout le monde n'est pas toujours d'accord (ex: libre selon la FSF mais pas Debian). Mais je trouve intéressant de garder à l'esprit que la liberté ce n'est pas absolue (comme tu le dis "ça dépend des sensibilités") ; par exemple, selon qu'on considère la liberté du matériel (ou qu'en fiche, parce que matériel on le change souvent, on veut juste que les spec soit publiques) on va se sentir libre ou pas.
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
n'est-ce pas? :)
En plus on peut voir une jolie nimage quand on on répond maintenant (vraiment, elle me fait toujours rire celle-la) :p
Certes, mais moi je parlais d'implémenter voire créer un format libre exploité par un logiciel non-libre, donc avec une contribution directe, bien que pas pure, au libre.
Ben si, dans les 2 cas on construit :D
Je plaisante bien sûr, tu as totalement raison.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Je ne me pose pas tellement la question "est-ce que le logiciel est libre" mais plutôt "est-ce que l'utilisateur est libre".
Un utilisateur sous windows, que son logiciel utilise des libs proprios ou pas, je pense qu'il s'en fiche un peu…
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
Et pourquoi ce serait différent sur d'autres OS?
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2. Dernière modification le 24 août 2017 à 15:10.
Ben si tu veux les quatre libertés tu commences par ne pas utiliser windows, non ?
¯\_(ツ)_/¯Edit: en fait j'ai ptet pas compris sur quoi portait ta question
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 3.
Je pense que tu n'as pas compris en effet:
Je voulais dire, même sous linux, mes logiciels libres peuvent utiliser des libs ou des outils proprio, par exemple utiliser les pilotes proprio de NVidia plutôt que nouveau pour des raisons de performance.
Cela n'empêche pas les logiciels libres d'êtres libres, bien qu'ils aient des dépendances envers des outils proprio.
Côté utilisateur, on peut très bien utiliser windows pour cause d'absence de choix (pas le propriétaire de la machine, par exemple) et maximiser son usage de logiciels libres: rendre l'environnement le plus libre possible.
C'est d'ailleurs comme ça que j'ai pu passer à Debian sans avoir un trop grand saut: le fait d'avoir libéré mon DE windows à 80% avec des logiciels portables (en plus d'être libres) m'a permit (il y a longtemps, certes) de passer à Linux.
Du coup, je trouve étrange de considérer qu'utiliser des logiciels libres ou non sous windows n'a aucune importance.
Je ne sais pas si je plus clair…
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Oui, mais l'utilisateur n'est pas libre, parce qu'il n'a pas les quatre libertés sur le code dont il dépend. Dans debian ce genre de programme ne pourrait pas aller dans le dépôt principal, il irait dans le dépôt
contrib, et aurait des dépendances dansnonfree.Si on n'est pas propriétaire de la machine, la question de la liberté ne se pose pas. C'est le propriétaire qui décide quel code tourne sur sa machine. Vouloir être libre sur une machine dont on n'a de toute façon pas le contrôle parce qu'elle ne nous appartient pas n'a pas de sens. C'est pour cela qu'on recommande à l'utilisateur qui veut être libre quand il fait son informatique de ne faire son informatique que sur une machine qu'il possède.
Si le but est de se familiariser aux logiciels libres sous Windows de manière à ne pas être complètement désorienté quand on arrive sur Linux, je ne pense pas que le fait que les logiciels utilisent des libs non-libres ait quelconque importance. Si tu passes de MS Office à LibreOffice pour retrouver les mêmes habitudes et les mêmes interfaces en passant ensuite à LibreOffice sur GNU/Linux, alors le fait qu'il y ait des libs non-libres sous ton LibreOffice n'est pas plus embêtant que le fait qu'il y ait un Windows non-libre (ce qui t'intéresse, c'est avant tout que l'interface soit la même).
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Booouuuh :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par freem . Évalué à 2.
D'un autre côté, j'ai prévenu qu'il fallait prendre mes propos avec des pincettes :)
Et un de qualité, en plus :)
Merci beaucoup pour ces explications.
[^] # Re: pas de FPS libre mono-joueur?
Posté par flan (site web personnel) . Évalué à 2.
Merci pour le message !
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Suivant le jeu que tu veux faire ce n'est pas nécessaire que les ennemis soient super intelligents ; alors que typiquement, quand les bots en multi sont idiots mais peuvent te mettre des tir à la tête avec un pistolet pourri à 300 mètres c'est énervant. Par exemple si tu combats des zombis, une IA très basique donnera un bon effet je pense.
Mais si tu dois décrire des scènes cinématiques en temps réel (tel personnage parle, tel autre intervient et la caméra va vers lui etc…) uniquement avec des lignes de code (par d'éditeur visuel), j'imagine que c'est clairement un frein.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . Évalué à 2.
Ah oui mais concevoir des levels et concevoir des cinématiques c'est pas le même boulot ! On peine déjà à avoir des cinématiques dans les jeux libres existants alors si on commence à dire qu'il en faut absolument pour faire un FPS linéaire, on n'en verra jamais de FPS linéaire !
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Évidemment il faut préciser de quoi on parle, parce qu'entre le mode solo d'un doom (suite de maps avec monstres/portes/armes) et le mode solo d'un Call of Duty (des couloirs séparés par des cinématiques :) ) c'est pas vraiment la même chose. Comme le commentaire initial parle de Half-Life (et que la dépêche est à propos d'un jeu en 3D), je suis parti de ce niveau d'exigence (donc des "cinématiques" en temps-réel assez basiques, genre un scientifique qui se fait bouffer juste quand tu arrives).
Je ne sais pas si c'était clair mais je parle de cinématiques en temps-réel, donc qui se passent dans le niveau où tu joues, avec des modèles de personnages du jeu. Et donc oui, ça demande sûrement des compétences différentes, mais:
# Activité
Posté par eingousef . Évalué à 4.
La dernière intervention de fr1tz sur les forums date d'Avril 2016. Il est toujours connecté au canal IRC mais n'y a aucune activité dessus depuis au moins 1 an (à part de temps un temps un quidam qui arrive pour demander des nouvelles et qui n'obtient aucune réponse). Aucune communication, aucune annonce de l'état de santé du projet. fr1tz pourrait tout aussi bien être mort sans qu'on le sache.
Et pour tout ceux qui comme moi ont donné pour la campagne de financement, ben…tant pis /o\
*splash!*
[^] # Re: Activité
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 20 août 2017 à 12:16.
Pour sa défense (même si je ne le connais pas ni son jeu avant cette dépêche), il avait demandé 1500$ et avait eu à peine plus. Il avait complètement sous-évalué un tel travail de manière évidente (il parle d'une version 1.0 en un mois dans son crowdfunding!), ce qui est compréhensible. Quand on est jeune (je suppose qu'il l'est, même si je ne vois aucun détail à ce sujet) et qu'on fait ce genre de crowdfunding sans être au préalable super connu, on a toujours peur de "demander trop" et de paraître irraisonnable donc de ne pas atteindre le financement (à raison, puisque ça marche effectivement beaucoup — pas entièrement ceci dit — comme cela, sur la base de réputation préalable, avec certaines bonnes et certaines mauvaises raisons).
Sans compter que l'évaluation de projet est très difficile, même après des années d'expérience (en entreprise, on dit en général qu'il faut multiplier sa plus longue estimation par 3 ou 4 ; de toutes façons, les commerciaux s'occuperont souvent de la diviser pour appâter le client).
Donc ~ 1500€… il pouvait pas durer bien longtemps. :-/
J'ai de l'empathie car je connais bien ça et on a fait le même genre d'erreur. On tient un peu plus car on est peut-être un peu plus persistant mais je pourrais pas en vouloir à quelqu'un qui a vraiment essayé (il a quand même bossé de janvier 2014 à février 2016 d'après la timeline et les commits ; pour 1697$ (moins les frais Indiegogo), on peut pas dire qu'il se soit barré avec la caisse :P), et qui a quand même sorti quelque chose (une version 0.1 après 7 mois) même s'il a pas fini/continué ensuite.
Peut-être qu'il aurait pu persister, essayer de continuer avec un second crowdfunding, etc. Mais c'est vraiment très dur de vivre ainsi (j'en sais quelque chose), surtout qu'il avait promis une 1.0 (grave erreur!) dans son financement précédent. Quant à craindre de faire face à ses contributeurs, je peux comprendre. Perso j'assumerais, ne serait-ce que parce que je continuerais de toutes façons à faire du Libre et que je n'aurais donc pas le choix, mais imaginez devoir affronter les "reproches" des gens plutôt que leur soutien. C'est pas facile. ;-(
C'est pourquoi, j'appelle à un peu d'empathie! :-)
Ceci étant dit, eingousef, je sais que tu es un grand contributeur et soutien de ce type de projets (films libres, jeux vidéos, etc.) et pour cela merci beaucoup. Tu es donc un gars très bien ;-) et pas un mauvais exemple (perso j'ai déjà eu des insultes car des trucs que je développais sur GIMP, et dont je faisais une démo, n'étaient pas encore disponible dans une version stable ; je dois le dire, c'est dur à vivre et parfois ça fait déprimer). Mais je sentais un petit fond de reproche dans ton commentaire… peut-être à tort?
Ensuite je comprends bien sûr la déception quand on a mis des sous (et donc cette personne a aussi des torts; notamment celui d'avoir mal évalué; même si encore une fois, c'est pas facile même pour les gens rompus à la tâche), mais je me fais l'avocat du diable sur ce sujet qui me touche personnellement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Activité
Posté par eingousef . Évalué à 3.
Oui, ça m'avait semblé très bizarre aussi. Mais comme le gars avait déjà fait plus ou moins le même jeu avant sur un autre moteur, que les assets étaient déjà prêts, etc, je me suis dit qu'il savait ce qu'il faisait.
En plus à l'époque j'étais loin de me douter que Torque3D était le pire choix possible en moteur de FPS libre. Aujourd'hui jamais je ne mettrai d'argent ou d'espoir dans un projet libre utilisant ce moteur.
C'est vrai qu'il y avait un peu de reproche dans mon commentaire précédent, mais c'est plus un reproche sur le silence radio du projet que sur l'absence de résultats.
*splash!*
[^] # Re: Activité
Posté par Pazns . Évalué à 3.
Pourquoi Torque3D était un très mauvais choix ?
Simple curiosité.
[^] # Re: Activité
Posté par eingousef . Évalué à 7.
Les développeurs de Torque3D se foutent royalement de Linux et du logiciel libre. Par exemple ils ont décidé de ne pas supporter les drivers libres (sauf ceux d'Intel).
Si vous voulez un bon moteur de FPS 3D, regardez du côté de ceux qui marchent bien, comme Daemon.
*splash!*
[^] # Re: Activité
Posté par RyDroid . Évalué à 1.
Source(s) ?
[^] # Re: Activité
Posté par eingousef . Évalué à 6.
Il ya un ticket ouvert depuis des années sur le git de Torque3D, ils ont juste pas envie de s'en occuper. Je ne le retrouve pas là, mais je me souviens que Calinou avait commenté dessus.
Quand on fait remarquer au développeur d'Uebergame que son jeu ne marche pas sous Linux, il dit "Utilisez les drivers officiels" (sic).
Sinon Daemon ça marche bien, c'est forké d'idTech 3, c'est utilisé par Unvanquished (pas libre mais pourrait devenir libre un jour), pourrait être utilisé par Xonotic (actuellement ils utilisent le bon vieux darkplaces mais ils ont envie de changer), et par un projet encore embryonnaire : unrealarena.
*splash!*
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.