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.
Disons que la civilisation perse achaménide est très mal documentée. Généralement il est assez difficile d'obtenir des informations sur les civilisations antiques de cette région-là du globe (achaménides, séleucides). Les historiens et artistes doivent donc faire un gros effort d'imagination.
Pour le bélier, je pense que les seules preuves que nous avons de son existence ressemblent à ça :
C'est ce type d'image qui a mon avis a dû prêter à confusion. On voit la tête du bélier heurter le mur au plus haut point de sa trajectoire, et les pierres tomber vers le bas. La protection frontale a probablement aussi dû suggérer un mouvement circulaire dans la tête des historiens/artistes.
Mais effectivement si on aborde la chose avec l'œil d'un physicien ça devient évident : un système de marteau attaché au plancher du bélier, soulevé avec des cordes par les opérateurs et qu'on laisserait tomber sur le mur ennemi nécessiterait de déployer énormément d'énergie pour un résultat médiocre (la distance traversée étant très courte et l'angle entre la trajectoire et le mur étant très resserré). Un système de bélier classique attaché au plafond de la structure par des cordes ou des chaînes puis balancé d'avant en arrière par les opérateurs aurait un bien meilleur résultat tout en permettant d'expliquer la protubérance en quart-de-cercle à l'avant de celui-ci (le point d'attache de la poutre doit pouvoir se déplacer le plus loin possible vers l'avant tout en restant protégé du feu ennemi).
Par contre je ne sais pas pourquoi le nouveau modèle n'est pas pourvu d'un toit couvrant la partie arrière du bélier contrairement à l'ancien.
… quand cette version sera-t-elle packagé dans debian ? En général, c'est assez rapide, mais avez-vous une date ?
Nope, je sais juste qu'il y a généralement quelqu'un qui s'en occupe à chaque release. Là ça fait presque 1 mois, c'est effectivement assez long (ptet que le packageur est en vacances ?).
The repacked source tarball distributed in Debian omits tools/lcc (the
bytecode compiler, which is non-free) and windows_scripts/*.exe (precompiled
Windows binaries for lcc and q3asm).
In a normal OpenArena build, QVM files would be built from these sources
using lcc. In Debian we build them as native-code using gcc instead.
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 ?
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.
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.
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 !
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).
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 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.
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).
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?
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.
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.
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".
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.
Tu parles de qc (quake code) ? Il me semble que ça n'a été abandonné qu'à partir de idTech 4.
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.
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 ?
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
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.
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.
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.
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.
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!)
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.
N'y a-t-il donc personne dans le libre qui ait envie de réaliser des compagnes solo?
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é.
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\
Je me souviens avoir lu ton journal l'année dernière, c'était très intéressant comme bilan sur le matériel libre.
Avant que le Zenitre te tombe dessus je tiens à rectifier : il s'agissait moins d'un journal sur le matériel libre que d'un journal sur la possibilité de faire tourner du logiciel libre sur du matériel (libre ou non).
C'est peut-être encore trop tôt pour faire un nouveau bilan mais est-ce que ça a beaucoup changé en un an ?
J'ai vu que RISC-V continue son bonhomme de chemin, LowRISC avance tranquillement. Comme tu le disais c'est du long terme.
Je pense que sur ce sujet il faudrait demander à quelqu'un qui connaît beaucoup mieux la technique que moi. Mes journaux se placent surtout du point de vue de l'utilisateur final, et de ce côté-là, il faudra attendre encore très longtemps pour voir du nouveau.
Niveau POWER, Raptor remet le couvert sur la prochaine famille d'IBM qui devrait arriver en fin d'année.
Je vais peut-être en parler bientôt (mais j'ai d'autres travaux en cours dans l'immédiat).
les SOC Freescale à base de GPU Vivante semblent être les seuls vraiment libérés
Le problème avec ARM c'est que le GPU est lié au CPU. Et les projets de matériel n'ont pas forcément le choix du CPU. Il y a des projets (Pyra, GTA04…) qui aimeraient bien avoir un GPU plus "libérable" (Adreno, Mali, Vivante…), mais pour ça il leur faudrait traiter avec d'autres fabricants de CPU et des conditions débiles du style "on ne vend rien à moins de 500000 unités". Donc si on regarde la partie CPU le marché ARM est plus libre que celui d'x86, si on regarde la partie GPU il est plus verrouillé. L'émergence d'une alternative est essentielle, entre autres pour cela.
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: bélier perse
Posté par eingousef . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 10.
Disons que la civilisation perse achaménide est très mal documentée. Généralement il est assez difficile d'obtenir des informations sur les civilisations antiques de cette région-là du globe (achaménides, séleucides). Les historiens et artistes doivent donc faire un gros effort d'imagination.
Pour le bélier, je pense que les seules preuves que nous avons de son existence ressemblent à ça :
https://commons.wikimedia.org/wiki/File:Assyrian_battering_ram.jpg
https://commons.wikimedia.org/wiki/File:Assyrian_Attack_on_a_Town.jpg
https://commons.wikimedia.org/wiki/File:Assyrian_siege_of_a_city,_showing_use_of_battering-ram.png
C'est ce type d'image qui a mon avis a dû prêter à confusion. On voit la tête du bélier heurter le mur au plus haut point de sa trajectoire, et les pierres tomber vers le bas. La protection frontale a probablement aussi dû suggérer un mouvement circulaire dans la tête des historiens/artistes.
Mais effectivement si on aborde la chose avec l'œil d'un physicien ça devient évident : un système de marteau attaché au plancher du bélier, soulevé avec des cordes par les opérateurs et qu'on laisserait tomber sur le mur ennemi nécessiterait de déployer énormément d'énergie pour un résultat médiocre (la distance traversée étant très courte et l'angle entre la trajectoire et le mur étant très resserré). Un système de bélier classique attaché au plafond de la structure par des cordes ou des chaînes puis balancé d'avant en arrière par les opérateurs aurait un bien meilleur résultat tout en permettant d'expliquer la protubérance en quart-de-cercle à l'avant de celui-ci (le point d'attache de la poutre doit pouvoir se déplacer le plus loin possible vers l'avant tout en restant protégé du feu ennemi).
Par contre je ne sais pas pourquoi le nouveau modèle n'est pas pourvu d'un toit couvrant la partie arrière du bélier contrairement à l'ancien.
*splash!*
[^] # Re: Super dépêche !
Posté par eingousef . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 2.
Nope, je sais juste qu'il y a généralement quelqu'un qui s'en occupe à chaque release. Là ça fait presque 1 mois, c'est effectivement assez long (ptet que le packageur est en vacances ?).
*splash!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: Activité
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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!*
[^] # Re: pas de FPS libre mono-joueur?
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: Activité
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: pas de FPS libre mono-joueur?
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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 eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: Activité
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: pas de FPS libre mono-joueur?
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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!*
# Activité
Posté par eingousef . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. É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: France
Posté par eingousef . En réponse au journal Troops, Trolls & Troublemakers : inventaire mondial de la manipulation organisée des réseaux sociaux. Évalué à 10. Dernière modification le 15 août 2017 à 10:25.
Il n'y a même pas la Suède, qui est le pays des trolls.
*splash!*
[^] # Re: Coquille
Posté par eingousef . En réponse au journal Btrfs ne serait plus le futur. Évalué à 3. Dernière modification le 14 août 2017 à 16:46.
si mais c'est rigolol :D
prout caca zizi
*splash!*
[^] # Re: question
Posté par eingousef . En réponse au journal Interview de Mark Nudelman, auteur de less et mainteneur actif depuis 34 ans . Évalué à 4.
Comment se fait-il que less ne contienne pas encore un éditeur de texte, un serveur mail, un jeu de démineur et un système d'init ?
*splash!*
[^] # Re: Sécurité
Posté par eingousef . En réponse au journal Interview de Mark Nudelman, auteur de less et mainteneur actif depuis 34 ans . Évalué à 6.
Ou alors il peut dire un truc subtil du style I was approached by people who were interested about "less security"
:P
*splash!*
[^] # Re: Point de vue d'un développeur XMPP
Posté par eingousef . En réponse à la dépêche Matrix pour décentraliser Skype, Whatsapp, Signal, Slack et Discord. Évalué à 0.
[:vomi]
*splash!*
[^] # Re: ARM / MIPS
Posté par eingousef . En réponse au journal Free Hardware Design, pour que le débat continue et que les initiatives se multiplient !. Évalué à 4.
Avant que le Zenitre te tombe dessus je tiens à rectifier : il s'agissait moins d'un journal sur le matériel libre que d'un journal sur la possibilité de faire tourner du logiciel libre sur du matériel (libre ou non).
Je pense que sur ce sujet il faudrait demander à quelqu'un qui connaît beaucoup mieux la technique que moi. Mes journaux se placent surtout du point de vue de l'utilisateur final, et de ce côté-là, il faudra attendre encore très longtemps pour voir du nouveau.
Je vais peut-être en parler bientôt (mais j'ai d'autres travaux en cours dans l'immédiat).
Le problème avec ARM c'est que le GPU est lié au CPU. Et les projets de matériel n'ont pas forcément le choix du CPU. Il y a des projets (Pyra, GTA04…) qui aimeraient bien avoir un GPU plus "libérable" (Adreno, Mali, Vivante…), mais pour ça il leur faudrait traiter avec d'autres fabricants de CPU et des conditions débiles du style "on ne vend rien à moins de 500000 unités". Donc si on regarde la partie CPU le marché ARM est plus libre que celui d'x86, si on regarde la partie GPU il est plus verrouillé. L'émergence d'une alternative est essentielle, entre autres pour cela.
*splash!*