0 A.D. : Empires Ascendant est un jeu vidéo de stratégie en temps réel (RTS) historique en 3D développé par Wildfire Games.
C'est un projet libre (code sous GNU GPL v3, données sous CC by-sa 3.0), au développement ouvert, visant des standards de qualité artistique comparables à ceux de l'industrie, ainsi qu'un grand respect de la réalité historique.
Le jeu, multiplate-forme et multilingue, permet d'incarner 12 factions qui ont marqué l'Histoire entre les rives de l'Atlantique et la chaîne de l'Himalaya, au cours de la période allant de -500 à -1.
0 A.D. : Empires Ascendant a été libéré en 2009. Depuis, le projet a eu un parcours mouvementé, tant sur le plan technique que sur les plans budgétaire et humain. Dernier challenge en date : recoder complètement l'algorithme de recherche de chemin (pathfinder), bout de code extrêmement complexe et jusqu'alors responsable de la majorité des ralentissements que subissait le jeu depuis plus de trois ans. Le 12 juin 2015, Nicolas Auvray (Itms), contributeur du projet, commite un nouveau pathfinder qui améliore de façon significative les performances de la version svn du jeu. En fin d'année 2015, alors que la version alpha 19 "Syllepsis" vient de sortir, équipée de ce nouveau pathfinder, nous avons le plaisir d'interroger Nicolas dans les colonnes de LinuxFr.org.
Bonjour Itms, peux-tu te présenter ?
Bonjour eingousef ! Et merci de m'accueillir sur LinuxFr.org :-)
Pour les présentations, je m'appelle Nicolas Auvray dans la vraie vie et j'étudie la physique à l'ENS de Lyon. Je suis aussi passionné par plein d'autres choses en dehors, en particulier la programmation et l'Antiquité, ce qui fait de moi une proie facile pour un projet comme 0 A.D. !
Comment en es-tu venu au libre en tant qu'utilisateur et développeur ?
Je ne sais pas exactement comment je suis venu au libre en tant qu'utilisateur, mais comme beaucoup d'autres français, j'ai découvert la programmation sur feu le Site du Zéro, qui à l'époque faisait découvrir non seulement des outils libres mais aussi l'envers du décor et nous incitait à participer en tant que développeurs débutants à des projets libres. Puisque je suis sur LinuxFr.org, c'est par exemple à cette époque que j'ai découvert Linux, et même si je continue à utiliser un OS privateur au quotidien, y compris pour développer, j'ai toujours quelques machines virtuelles sous la main !
Comment as-tu découvert 0 A.D. et commencé à y contribuer ?
J'ai découvert 0 A.D. via un blog que je suis depuis un longtemps, celui de Dedoimedo, un blogueur qui a un avis (parfois très tranché) sur un peu tout, qui a consacré plusieurs posts au jeu il y a un certain temps. Je suis tout de suite tombé amoureux du jeu parce que c'était un projet très accueillant qui m'a tout de suite donné envie de contribuer, parce que je suis passionné par cette période antique et ses cultures, et que j'ai beaucoup joué à des jeux de type RTS. Malheureusement, je n'ai pas pu commencer à participer, parce que j'étais en prépa ! Mon idée de contribuer à 0 A.D. a donc dû sommeiller un bout de temps, et c'est à la rentrée 2013, en arrivant dans mon école (et en retrouvant une vie) que j'ai proposé mes premiers patchs pour le jeu et que j'ai commencé à rencontrer les gens de la communauté.
Tu as donc pu suivre le cheminement du jeu entre 2010 et 2012 si j'ai bien compris, grosso-modo sur les 12 premières alphas, en plein dans la période de "renaissance" de 0 A.D. Comment as-tu vu évoluer le projet depuis que tu y es impliqué ?
Non, pas vraiment, parce qu'en prépa je n'ai pas pu suivre grand chose ! C'est en sortant que je me suis souvenu de 0 A.D. Depuis que je suis impliqué dans le projet, il y a eu très peu de gros changements à mon avis, on fonctionne toujours à peu près de la même façon, mais on approche de plus en plus de la bêta et du coup il y a de moins en moins de nouveautés dans le code et les sorties de nouvelles versions s'espacent de plus en plus. On essaie de contrer ce phénomène parce que c'est mauvais pour attirer des contributeurs, vu qu'une nouvelle version ça nous donne beaucoup de visibilité.
Effectivement le projet a eu des hauts et des bas, mais il continue à avancer, quelles sont les barrières qu'il reste à franchir ?
La barrière majeure qu'il nous reste à franchir, c'est un problème d'équilibrage du jeu. Il faut rendre le jeu agréable à jouer, et c'est tout un métier ! Il y a un juste milieu à trouver entre profondeur de jeu et simplicité, et dans notre cas on doit aussi tenir compte du réalisme du jeu, parce qu'un des objectifs est d'avoir un jeu le plus exact possible historiquement. Malheureusement les fondateurs de 0 A.D. sont en grande partie inactifs désormais, et on ne peut pas se contenter du retour des joueurs sur ce point parce que tout le monde a une opinion différente, on ne peut pas faire un jeu qui plaise à tout le monde.
Au niveau des défis qu'il nous restent à franchir du point de vue "programmation", on est face à un problème de performance qui nécessite énormément d'investissement. On a nettement amélioré les choses dernièrement, mais l'optimisation du jeu est un défi qu'on ne peut pas relever d'un coup, on doit procéder par petites touches. En particulier, une grosse source de ralentissement venait de nos algorithmes de recherche de chemins, ce qui est un problème récurrent dans le développement de jeux vidéos ! Récemment, j'ai intégré au jeu un nouvel algorithme pour les chemins longs, mais celui pour les chemins courts reste une source de problèmes. Personnellement, cette année scolaire je n'ai que très peu (voire pas) de temps à consacrer à 0 A.D., mais il s'agit d'une de mes priorités pour quand ma vie sera moins chargée !
Nous avons effectivement eu plusieurs fois l'occasion d'évoquer le code de recherche de chemin, ou "pathfinder" en anglais, sur LinuxFr.org dans les annonces relatives à 0 A.D.. Mais pour les lecteurs qui ne seraient pas très familiers avec le concept, est-ce que tu pourrais expliquer ce qu'est un pathfinder, son rôle et comment il opère ?
L'objectif de la recherche de chemins, c'est de permettre au jeu de trouver les plus courts chemins entre deux points en présence d'obstacles. En effet, les humains sont très doués pour déterminer de tels chemins, c'est quasiment instinctif, mais du point de vue de l'informatique théorique c'est un problème extrêmement complexe. Du coup, la complexité ça se traduit par un nombre très important de calculs à effectuer et ça diminue les performances du jeu (en clair, ça fait lagger ;-) ) Dans 0 A.D., la recherche de chemins est essentielle pour deux systèmes : les unités, qui doivent trouver comment aller de leur position actuelle à celle que le joueur leur indique, et l'intelligence artificielle (l'IA), contre qui on peut jouer en mode solo, qui peut avoir besoin de déterminer un chemin qui évite la base de l'adversaire, etc. Il faut aussi savoir que le pathfinder est couplé à la détection des collisions, parce que si l'unité calcule un chemin, et que durant son déplacement un bâtiment est construit, elle doit le détecter et le contourner, par exemple. De manière générale, le gros problème n'est pas de trouver le plus court chemin (c'est bien sûr la ligne droite), mais plutôt d'éviter les collisions.
Donc plutôt que d'avoir un pathfinder qui explore tous les chemins possibles après le point de départ, ce qui consommerait beaucoup trop de ressources, on utilise un pathfinder qui va d'abord essayer la ligne droite, puis, s'il rencontre un obstacle, chercher dans toutes les directions de façon incrémentale, puis choisir le meilleur chemin parmi ceux qu'il a trouvé pour contourner l'obstacle, c'est cela ? Ou bien c'est plus complexe ?
C'est à peu près ça : tu as grosso modo décrit la différence entre l'algorithme de Dijkstra et le A* que nous utilisons pour le pathfinder longue portée. En réalité c'est légèrement plus compliqué mais les pages Wikipédia des deux algorithmes expliquent ça très bien ! Et pour les lecteurs plus versés en algorithmique, un des changements du nouveau pathfinder est d'utiliser l'optimisation dite "Jump point search" (je traduirais ça par "recherche par sauts" mais je ne connais pas la traduction officielle) qui est particulièrement efficace car dans 0 A.D., tous les chemins de même longueur sont équivalents (il n'y a pas de zones plus difficiles à traverser que d'autres).
[NdR : Représentations de processus de recherche de chemin entre un point de départ et un point d'arrivée, sur une carte disposant d'un obstacle entre ces deux points, l'un utilisant l'algorithme de Dijkstra, l'autre utilisant l'algorithme A*. On voit bien la différence de rapidité entre les deux algorithmes sur un cas pratique courant.]
Quelles sont les particularités du pathfinder de 0 A.D., et en quoi celui-ci diffère-t-il des pathfinders des autres jeux libres (Megaglest, Warzone 2100…) ?
Je ne connais pas trop les pathfinders d'autres jeux, malheureusement. Les particularités du pathfinder de 0 A.D., c'est probablement d'en avoir deux : un à courte distance et un à grande distance. L'idée, c'est que si on décide de prendre en compte toutes les collisions possibles, avec les bâtiments, les unités qui bougent, etc, on va faire planter le jeu, purement et simplement, c'est bien trop complexe. Donc on calcule un chemin "long", qui ne prend en compte que les obstacles fixes, et si jamais on entre en collision avec quelque chose, on calcule un chemin local avec le pathfinder courte portée, qui est moins efficace car il regarde tout, mais c'est compensé par le fait qu'il ne regarde que peu d'objets, ceux qui sont proches. Une autre particularité est que l'IA du jeu, Petra, est très aboutie et a donc des besoins assez importants, le pathfinder doit donc être capable de les satisfaire.
Je crois savoir que beaucoup de contributeurs se sont relayés les uns après les autres sur le développement du pathfinder de 0 A.D., est-ce que tu pourrais nous donner plus de détails sur l'historique de celui-ci, avant et après la refonte ?
Je ne connais pas trop l'historique de l'ancien pathfinder. Quand je suis arrivé, Philip Taylor (Ykkrosh), qui est le programmeur qui a entièrement réécrit le code de la simulation (c'est-à-dire les unités, les bâtiments, les attaques, les ressources, etc.) de 0 A.D. au moment où le jeu est devenu libre et open-source (c'est vous dire le niveau de cet homme !), avait écrit un prototype de nouveau pathfinder avant de devoir se retirer de l'équipe par manque de temps. Le nouveau pathfinder introduisait un graphe des régions de la carte connectées, pour pouvoir optimiser pas mal de fonctions, et ajoutait la fameuse optimisation "Jump Point Search" au pathfinder à longue portée.
Du coup ce nouveau pathfinder prenait la poussière sur un dépôt git, et une ou deux personnes qui avaient essayé de le finir et de l'intégrer au jeu avaient abandonné : je pense à quantumstate, qui n'était déjà plus actif quand je suis arrivé, mais je crois qu'il y a eu d'autres tentatives. D'ailleurs quantumstate avait déjà écrit le pathfinder de l'IA, donc il a été important dans l'historique de ce système. À l'été 2014, wraitii s'est à son tour lancé et a dû arrêter par manque de temps mais j'ai accepté de continuer son travail, et, cette fois, ça nous a vraiment permis d'avoir une base solide pour l'intégration du code. J'y ai passé presque un an, j'ai reçu l'aide de kanetaka, un contributeur occasionnel qui avait proposé un patch pour l'ancien pathfinder qu'on a intégré dans le nouveau, et qui a corrigé quelques bugs et ajouté des optimisations. J'ai aussi eu un coup de main de la part de mimo, qui est le développeur qui s'occupe de l'IA en ce moment, et de sanderd17 qui a corrigé quelques bugs de dernière minute. Et enfin, depuis le "commit" de ce code en juin, j'ai introduit quelques optimisations et corrigé toujours plus de bugs. :-)
Visiblement les premiers travaux sur le nouveau pathfinder datent de bien avant la focalisation sur les problèmes de performance : qu'est-ce qui posait problème avec l'ancien pathfinder et pourquoi fallait-il en écrire un nouveau ?
Le nouveau pathfinder a quand même été écrit pour améliorer les performances : ce problème a toujours été critique, même si on ne se focalise plus dessus en ce moment parce que le projet est plus avancé. Le problème essentiel de l'ancien pathfinder (qui n'impactait pas seulement la performance d'ailleurs), c'est qu'il ne savait pas si deux points de la carte étaient accessibles l'un à partir de l'autre. Ça le limitait énormément, et bien sûr ça causait aussi d'affreux ralentissements quand le joueur (ou, plus souvent, l'IA) demandait aux unités d'aller d'un endroit à un autre non accessible et que le jeu tentait de calculer des chemins impossibles. Ça se voit pas mal sur les illustrations de Dijkstra et de A* mises plus haut : si jamais tu trouves un chemin, le calcul est fini, mais si il n'y en a pas, il faut tester tous les chemins possibles avant de s'arrêter !
La connaissance de l'accessibilité d'une zone de la carte à partir d'une autre, l'inclusion de l'optimisation Jump Point Search dont tu as parlé (si j'ai bien compris il s'agit de représenter l'espace en un ensemble de "nœuds" interconnectés et de lancer dessus un dérivé de l'algorithme A* (JPS donc), optimisé pour ce type de représentation)… Quelles autres différences techniques y a-t-il entre le nouveau pathfinder et l'ancien ?
Il y a plein de petites choses qui ont changé mais globalement ce sont les deux changements majeurs au niveau du design.
À part ça, un changement assez technique a été effectué au niveau de la gestion des obstructions, dans le but d'accélérer la recherche de chemins : pour simplifier, les bâtiments et autres obstructions sont maintenant traités comme des zones infranchissables de la carte elle-même (comme l'eau ou les pentes escarpées). Ça accélère drastiquement la recherche de chemins, mais ça oblige à mettre à jour la carte en permanence, parce que les bâtiments sont construits, détruits, etc. Du coup pour que le bilan soit favorable, j'ai dû réécrire ce nouveau code qui "aplatit" les obstructions sur la carte.
Enfin, j'en ai parlé un peu plus haut, le nouveau pathfinder est accessible par l'IA (qui est écrite en JavaScript pour pouvoir être moddée) et donc on a pu se débarrasser du petit pathfinder personnalisé de l'IA, qui mangeait énormément de ressources et qui avait été introduit de manière temporaire.
Comment en es-tu arrivé à travailler sur le pathfinder de 0 A.D. et quelles étaient les particularités de ton travail au sein de Wildfire Games (qualités demandées, niveau de difficulté, salaire, temps, moyens…) ?
Ça s'est fait comme ça, wraitii n'était plus dispo pour continuer son travail, au cours d'un meeting on a décidé que je reprendrais le projet, avec l'aide de l'équipe bien entendu. On passe tous beaucoup de temps sur le jeu, on se sent quand même responsables du développement, mais notre travail est 100 % bénévole ! Pas de salaires ou autres, seulement de la motivation et une excellente ambiance. La difficulté et les qualités, ça dépend beaucoup des tâches, il y a beaucoup de choses très simples et quelques problèmes très compliqués (comme le pathfinder). Très peu d'entre nous sont aussi des développeurs dans la vraie vie, donc pour la plupart c'est face à un problème qu'on apprend à le résoudre, on ne dispatche pas les tâches en fonction des compétences de chacun, mais plutôt en fonction de ce sur quoi on aimerait travailler. Et on est très très contents quand des contributeurs nouveaux ou occasionnels nous aident ! Même les tâches simples demandent beaucoup (trop) de temps donc quand on reçoit de l'aide le jeu avance à plus grands pas ! Et pas besoin d'être une divinité de la programmation pour nous donner un coup de main ;-)
La communauté 0 A.D. n'a pas de divinités mais elle a ses héros, et pour beaucoup de fans du jeu tu as rejoint ce panthéon en permettant au projet de refonte du pathfinder d'atteindre son premier jalon (la finalisation du pathfinder longue-distance), et de revenir à des performances décentes dans la version alpha 19 du projet (un véritable soulagement !). Mais tu as dit que tu continuais à travailler sur le pathfinder et les performances, que reste-t-il encore à faire ?
Il s'agit essentiellement de travailler sur le pathfinder courte portée, qui ne pose pas d'énormes problèmes mais qui correspond tout de même à une grande partie du temps de calcul passé sur la simulation. Il est probablement possible de l'optimiser, et Philip avait également proposé le design d'un nouveau système, qui réduirait énormément notre utilisation du pathfinder courte portée. Mais je ne peux pas vraiment en dire plus avant de programmer et de tester le gain en performance ! Et bien évidemment, il reste des bugs à corriger, qui ont été introduits par le nouveau pathfinder, et qui seront résolus au fur et à mesure qu'on les découvrira. On peut compter pour cela sur elexis, le dernier arrivé dans l'équipe de développement, qui fait depuis son arrivée dans la communauté un travail incroyable de test du jeu pour repérer tous les problèmes !
Comment comptes-tu contribuer dans le futur, à 0 A.D. ou éventuellement d'autres projets libres ? Est-ce que tu peux nous dire deux mots sur tes contributions en-dehors du pathfinder ?
Eh bien pas de projets en particulier, je vais continuer à contribuer sur mon temps libre, sur ce qui me paraît important ! J'ai bien quelques patches en préparation, mais tant qu'ils ne sont pas prêts je préfère ne rien dévoiler ;-) Quand à d'autres projets libres, ça serait super mais je crains de ne pas du tout avoir le temps !
En dehors du pathfinder, ma plus grosse contribution a sans doute été de cacher les changements aux bâtiments dans le brouillard de guerre (ça a été introduit dans la version A17). Ça a été très difficile de faire ce système et on continue encore à trouver des bugs cachés liés à la visibilité des entités du jeu ! À part ça, j'ai fait énormément de petites et moyennes choses (la liste est trop longue et peu intéressante) ! Et en dehors de la programmation, je coordonne la traduction française, je travaille un peu sur les langues anciennes (les voix des unités et les textes) et je m'occupe du compte Twitter @play0ad.
Tu as dit qu'avec le départ de la plupart des membres fondateurs, le projet partait un peu dans des directions différentes, et que rééquilibrer le jeu pour le rendre plus agréable à jouer constituait la prochaine grosse étape. D'une façon plus générale, comment vois-tu 0 A.D. évoluer dans le futur (tant au niveau gameplay que art, code, technologies utilisées, etc.) ?
Je ne sais pas trop quelles nouvelles choses vont apparaître dans le jeu, mais je pense qu'on approche de plus en plus d'une version bêta et que le gameplay va de moins en moins changer. Il reste quand même à prendre une décision sur les formations, sur l'agriculture et possiblement d'autres choses qui peuvent avoir une grosse influence sur le ressenti des joueurs et des joueuses. Au niveau de l'art, il reste à terminer les bâtiments Séleucides et leur musique, et ça serait génial de pouvoir inclure les nouveaux modèles d'unité créés par Enrique, mais on manque d'animateurs 3D ! C'est sur ces domaines qu'on va se concentrer principalement.
Avec ton expérience actuelle au sein d'un gros projet communautaire, quels conseils donnerais-tu à une personne qui voudrait contribuer à un projet de jeu vidéo libre (que ce soit dans le domaine du pathfinding ou en général) ?
Un seul conseil : foncez ! Avec toujours l'envie de faire les choses bien et de toujours accepter les critiques des autres contributeurs, mais ne vous auto-censurez surtout pas ! C'est en essayant de faire des choses apparemment très difficiles et intimidantes qu'on réussit à les faire, et les progrès et les découvertes que vous pourrez faire en contribuant à un projet libre (jeu vidéo ou autre d'ailleurs) seront innombrables.
As-tu quelque chose à ajouter ?
Je voudrais dire "venez contribuer !" mais c'est essentiellement ce que je viens de dire dans la question précédente sur les conseils. En tout cas soutenir le projet, c'est jouer au jeu, en parler autour de soi, convertir des joueurs de RTS plus connus mais payants, etc ! Même si vous ne programmez pas ou ne faites pas de graphisme, vous pouvez grossir nos rangs !
Merci beaucoup Nicolas pour tes réponses et le temps que tu nous as accordé, à moi et aux lecteurs de LinuxFr.org, et bon courage pour tes contributions futures !
Et encore merci à toi et à LinuxFr.org pour cet entretien !
Aller plus loin
- Site officiel (994 clics)
- Compte twitter (83 clics)
# gz
Posté par EauFroide . Évalué à 9. Dernière modification le 22 janvier 2016 à 14:46.
Ça fait 2-3 jours que je me suis mis a ce jeu et il est franchement sympa !
Quelques améliorations qui pourraient être sympa :
1) La possibilité de désactiver le GPU (surchauffe sur certains portable (genre Acer) peu importe l'OS) pour utiliser le CPU.
2) Lorsqu'on zoom via molette, centrer l'écran sur la souris plus tôt que zoom sur le centre de l'écran, voir pourquoi pas afficher la map lorsqu'on dé-zoom complètement (c'est le système dans Suprême commander)
3) augmenter le nombre de joueurs/IA sur une map
Petit soucis :
Je n'arrive pas a grouper les unités, d'après ici http://trac.wildfiregames.com/wiki/HotKeys c'est CTRL+nombre pour grouper et nombre pour sélectionner (j'ai testé sur la version de base dans Ubuntu ainsi que la dernière version).
A part ça, le reste est vraiment bien foutu, on sent l'inspiration de la série Age of (surtout mythology côté graphisme) et de Civilization (système de frontière culturelle).
Le jeu est vraiment beau visuellement et on peut mettre a Infini la limite de pop comme dans CAC (par contre ça lag: les IA se goinfre vite en ouvriers).
Petite question en passant, est-ce que les arbres repoussent ? :)
PS: merci pour ce jeu qui est un des meilleurs côté libre :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: gz
Posté par rockn (site web personnel) . Évalué à 8.
Salut,
J'y joue régulièrement en réseau avec un pote.
Pour les création de groupe, voici ma config qui marche bien :
À mettre dans un fichier local.cfg dans ~/.config/0ad/config/. Voir default.cfg.info pour les réglages de base. On peut bien sur assigner plus que ces 4 raccourcis.
Donc "Shift + A" pour créer un groupe, "Shift+Alt+A" pour ajouter la sélection à un groupe et enfin "A" (en minuscule) pour pour sélectionner le groupe.
Pour pouvoir choisir le nombre de joueurs/IA il faut mettre Type de carte : Aléatoire, ça permet ensuite de choisir jusqu'à 8 joueurs.
Et non les arbres ne repoussent pas ;)
[^] # Re: gz
Posté par EauFroide . Évalué à 2.
merci pour l'infos ;)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: gz
Posté par eingousef . Évalué à 6. Dernière modification le 22 janvier 2016 à 22:43.
Je ne sais pas si c'est réaliste comme fonctionnalité, il y a d'autres jeux qui ont ça ? J'ai bien peur que déplacer les opérations GPU vers le CPU risque de faire ramer énormément le jeu (surtout pour 0 A.D.).
Mais bon si ça ne te paraît pas déconnant tu peux créer un rapport de bug (ça m'étonnerait qu'il y ait déjà un ticket qui demande ça).
En attendant je te conseille de désactiver la plupart des effets graphiques (ombres, particules, eau HD, etc.) pour solliciter le GPU le moins possible. Autre conseil : ne pas jouer sur un laptop, en tout cas pas de façon régulière. À l'exception de trucs très haut de gamme faits par des marques qui prennent les joueurs très aux sérieux, les laptops qu'on trouve dans le commerce de nos jours sont presque toujours fragiles, mal finis, mal ventilés, trop compacts, mal aérés, et ont une espérance de vie assez faible. Bref, pas fait pour le jeu (quoi qu'en disent les pubs).
Les claviers français nécessitent de presser Shift pour accéder aux chiffres, et peu de jeux sont compatibles avec ce comportement. Il te faudra remapper ces touches, soit en remplaçant 12345… par &é"'(… etc soit en utilisant les touches du keypad.
*splash!*
[^] # Re: gz
Posté par EauFroide . Évalué à 1.
Oui c'est effectivement la ventilation du portable qui foire, n'ayant hélas pas les moyens de me payer une tour pour le moment.
Pour information, j'ai tenté avec le clavier numérique a droite et ça ne fonctionnait pas non plus, je vais tenter le mapping comme rockn et toi le conseillez.
Petite question: y a-t-il des échanges de codes, de bon procédé et de graphismes entre 0ad et les autres jeux? (genre TA Spring par exemple) :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: gz
Posté par eingousef . Évalué à 3.
Il ne doit pas être mappé par défaut alors, il faut le mapper soi-même. Dans le fichier de config les touches du keypad s'appellent "Num1", "Num2", etc. En cas de doute regarde le fichier keys.txt dans le répertoire de config.
Je ne pense pas qu'il y ait des échanges de code avec Spring, 0 A.D. utilise son propre moteur : Pyrogenesis.
Par contre il y a des échanges de graphismes : Stunt Rally a repris des modèles de 0 A.D. et cela a fait l'objet d'un journal sur Linuxfr.org : https://linuxfr.org/users/bluestorm/journaux/stunt-rally-course-de-voitures-reutilise-les-graphiques-de-0-a-d-strategie-antiquite Je ne sais pas si c'est définitif par contre.
*splash!*
[^] # Re: gz
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Sous GNU/Linux tu peux faire cela :
(tu peux remplacer
0adpar n’importe quel programme OpenGL, il utilisera alors le rendu CPU via LLVMpipe).Mais j’espère que tu as un CPU très costaud, et que lui est bien ventilé…
Je te conseille de ne rien activer dans les "Paramètres graphiques" exceptés :
Tu dois pouvoir activer la limitation Vsync et le taux de rafraîchissement dans les menus, mais je doute que tu arrives à dépasser la fréquence de rafraîchissement de ton écran… ;-).
Dans "Général" active "Mode fenêtré" et "Surcouche FPS" (pour vérifier que tu y gagnes…) et laisse les options activées par défaut, actives.
Ferme et relance 0ad. J’ai essayé et perso j’atteins péniblement 15fps mais mon CPU n’est pas un veau. Ça reste à peu près supportable vu que c’est pas un Quake-like. À mon avis dès que le jeu va se corser (avec des tas de persos qui cherchent leur chemin etc.), ta machine va être vraiment à genoux…
Un GPU c’est tout de même fait pour quelque chose. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: gz
Posté par eingousef . Évalué à 2.
En fait la plupart des options graphiques un peu poussées nécessitent GLSL d'activé pour fonctionner. GLSL a été activé par défaut récemment, probablement dans l'a19. Il faudrait reprendre le fichier de config des versions précédentes pour pouvoir désactiver GLSL sans risque (mais du coup ça va désactiver la plupart des autres options).
*splash!*
[^] # Re: gz
Posté par EauFroide . Évalué à 2.
Ouaaa, ta commande fonctionne Thomas DEBESSE.
Par contre je ne m'attendais pas a ce que mon i5 soit aussi pourrave, je tourne avec … … … 2 FPS :P (et c'est juste en début de partie, j'imagine pas en 3 vs 3 avec 300 pop par culture :P )
PS: oui, on sait tous que le GPU c'est super utile, le problème c'est la ventilation des pc moderne :( (je ne peux même plus miner des DogeCoin/DarkCoin avec mon GPU) Le truc le plus bizarre est que mon soucis de ralentissement est apparut plus de 6 mois après l'acquisition de la machine hors, après ouverture/démontage, il n'est pas encrassé :(
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: gz
Posté par eingousef . Évalué à 4.
WHAT o_O
Tu mines des machin*coins avec le GPU de ton portable ? O_o Pas étonnant que tu niques ton matos ! Arrête tout de suite. C'est du suicide.
*splash!*
[^] # Re: gz
Posté par EauFroide . Évalué à 1.
Ouai je confirme que c'est à éviter, je ne l'ai fait que pour le délire d'essayer et j'ai eu deux redémarrage suite aux surchauffes mdr
Mais ce fut instructif sur le capacité de mon GPU (pièce maîtresse de ma machine): à peine capable de tenir à plein régime uniquement quelques minutes avant de surchauffer. (je n'ai pas trouvé mieux pour "chiffrer" les capacités d'un GPU afin de comparer à d'autres GPU)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: gz
Posté par eingousef . Évalué à 3. Dernière modification le 23 janvier 2016 à 13:46.
Hum d'une part si tu veux tester les capacités de ton hardware il existe des logiciels de benchmark pour ça (je pense à la phoronix test suite mais il y en a sûrement d'autres), d'autre part ces logiciels de benchmark lancent une batterie de tests sur ton matos, chaque test correspondant à une exploitation différente de celui-ci. Là par exemple, en minant des *coins, tu as tout juste testé les capacités de calcul OpenCL de ton GPU (et du driver associé, qui ne les exploite pas forcément de façon optimale), ce qui te permet de savoir comment se débrouille ton ordinateur par-rapport à d'autres ordinateurs en terme de calcul OpenCL, mais qui ne va pas te donner beaucoup d'indications sur comment il se débrouille sur les jeux 3D par exemple.
Edit: Après si ton objectif c'était de tester la ventilo, voir combien de temps ton PC pouvait tenir en surchauffe avant que ça plante, ouais, le minage de *coin est probablement un des meilleurs tests.
*splash!*
[^] # Re: gz
Posté par eingousef . Évalué à 3.
Ce n'est pas très étonnant.
Déjà 0 A.D. est un jeu qui sollicite énormément le CPU, notamment à cause du code mal optimisé (des progrès ont été fait de ce côté-là mais il en reste beaucoup à faire). Alors si en plus tu lui demandes de faire des calculs qu'il a énormément de mal à faire (comme le dit illwieckz, c'est pas pour rien qu'on a inventé les GPU), il va se retrouver à plat assez vite. Et à cela il faut ajouter le fait que le jeu est pour l'instant monothreadé : un seul cœur du CPU est exploité. Je ne sais pas comment ça se passe avec le softpipe, si les opération GPU sont monothreadées aussi ou si elles sont réparties sur tout le CPU, mais elles sont monothreadées ça doit rendre les choses encore pire effectivement :)
*splash!*
[^] # Re: gz
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
LLVMpipe sait utiliser jusqu’à 8 cœurs (par défaut il prend tous les cœurs disponibles, on peut réduire avec
LP_NUM_THREADScf. cette page.Perso, des trucs comme Quake3 tournent avec un framerate décent avec mon CPU uniquement, mais c’est un jeu qui a plus de 16 ans…
Pour revenir au mining etc. Les GPU de portables sont généralement étudiés pour n’être utilisés qu’au ralenti la plupart du temps.
Par exemple, il y a 8 ans j’ai eu des problèmes avec mon Thinkpad X61T (ultraportable convertible tablette) au début de Gnome Shell. Pourquoi ? Parce que même si cet ordinateur était préinstallé avec Vista (qui fait de la composition), ben les concepteurs avaient encore pensé « comme avant », quand tout était fait par le CPU et que le GPU n’était utilisé qu’occasionnellement, pour des jeux par exemple. Sauf qu’à partir du moment où le wm fait de la composition, le GPU est exploité 100% du temps, et j’ai eu des problèmes inattendus de températures et d’autonomie… Il semble que le problème a été résolu logiciellement depuis, probablement du coté des pilotes, peut-être que du coté des pilotes aussi les développeurs s’étaient dit « boah, la 3D sur cette config c’est occasionnel, pas besoin de faire attention », sauf qu’avec compiz/mutter/autre, la 3D c’était tout le temps…
De même pour quasiment tous les portables aujourd’hui, ils sont faits pour encaisser la composition de Windows en continu, faire tourner des jeux occasionnellement, mais pas faire du calcul sur GPU de manière durable… Miner des
*coinsça implique de laisser le matos tourner tout le temps à fond, et les portables sont rarement prévus pour cela, tu va abîmer ton matériel (si ce n’est déjà fait), ne serait-ce qu’en surchauffe, et tu peux aussi user tes ventilateurs prématurément. C’est typiquement ce qui s’est passé avec mon Thinkpad (l’usure du ventilateur à cause de la surchauffe induite par la composition). D’ailleurs, certains ne font pas qu’endommager leur ordinateur.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: gz
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Et du coup le passage a du multi-thread est-il un chantier prévu ? J'imagine que le boulot doit être assez conséquent, mais on peut rêver. :)
[^] # Re: gz
Posté par eingousef . Évalué à 3.
Oui, mais :
1) Il faut optimiser le code du jeu avant de le multithreader. L'implémentation du multithread sera la dernière étape de la longue liste des optimisations à faire pour rendre le jeu plus rapide.
2) Le moteur de jeu est vieux et date d'avant les multicores. La séparation des tâches dans plusieurs threads est possible, mais elle ne sera jamais parfaite.
*splash!*
[^] # Re: gz
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Oui tout à fait.
Exploiter parfaitement une machine est déjà quasi-impossible, surtout avec un code ciblant des architectures diverses. Et le faire avec du code parallèle est forcément encore plus dur.
Pourtant je trouve que ce que tu dis est triste. Oui il est tout à fait possible que le moteur n'exploite jamais très efficacement les multicores ; parce que le développement, uniquement porté par des bénévoles, est lent, et que du coup le projet pourrait en effet être moribond bien avant ça. Mais dans l'absolu, le fait de voir un jeu sans cesse amélioré (plutôt que sorti une fois pour toutes, et abandonné par son studio, passé à un autre projet) est plutôt enthousiasmant, aussi je préfère ne pas dire "jamais" tant que le projet vit.
Il y a en gros 2 axes pour multithreader un jeu:
J'ai instinctivement tendance à penser que pour un RTS la 2ème technique est plus facile à implémenter que pour d'autres genre ; du fait par exemple qu'on pas mal d'entités statiques (les bâtiments) qui, si suffisamment éloignées ne vont pas interagir ensemble (évidemment ça dépend des règles) ; après lorsqu'on a plein d'unités au même endroit qui se tapent dessus ça devient peut-être assez infernal à faire efficacement, alors je ne m'avancerai pas trop non plus, il est clair que c'est complexe. Ça ferait sûrement un passionnant GSoC :)
[^] # Re: gz
Posté par eingousef . Évalué à 3. Dernière modification le 23 janvier 2016 à 22:38.
Voilà, c'est ça qui sera fait si j'ai bien compris. Il est notamment question de déplacer l'IA dans un autre thread, et probablement d'autres éléments. Et comme tu l'as expliqué, suivant la consommation de chaque élément, certains cœurs se retrouveront plus sollicités que d'autres. Ça ne devrait pas être trop grave car une fois que toutes les optimisations auront été faites, le jeu devrait tourner correctement avec les paramètres par défaut même en n'exploitant qu'un seul cœur. Et après ça le multithread, c'est du bénef' :)
Par contre il n'est pas question d'aller plus loin. Le moteur du jeu est très ancien et le modifier de manière à pouvoir séparer finement chacune des entités du jeu pour les faire tourner dans des threads en évitant tout conflit serait un travail colossal. Lorsque les problèmes de performances seront résolus et le multithread "basique" implémenté, on devrait être aux alentours de la fin de la période beta et de la sortie de la première version stable de 0 A.D. Part 1 : Empires Ascendant. Les développeurs seront alors déjà en train de travailler sur 0 A.D. Part 2 : Empires Besieged, qui devrait utiliser un nouveau moteur au lieu du vieillissant Pyrogenesis. Il est encore trop tôt pour dire si les développeurs vont écrire un Pyrogenesis 2 ou utiliser un moteur déjà existant (au moins pour le rendu).
Donc non, le multithreading "fin" de 0 A.D. Part 1 ne fait pas partie de la feuille de route de WFG parce qu'il n'ont probablement pas le temps ni l'effectif pour ça. Par contre oui, il est toujours possible qu'un jour des développeurs tiers se penchent sur la question (perso je ne tablerais pas dessus mais bon). Quant au GSoC, ça n'est pas non plus dans les moyens humains de WFG.
*splash!*
[^] # Re: gz
Posté par GuieA_7 (site web personnel) . Évalué à 2.
OK merci pour ta réponse précise.
Cool.
Je pensais qu'être juste mentor permettait un investissement en temps assez faible (tout est relatif évidemment).
[^] # Re: gz
Posté par eingousef . Évalué à 3.
Bne non justement, en tout cas pas d'après les développeurs de 0 A.D.. D'après eux, il faudrait des développeurs connaissant bien le sujet qui soient constamment derrière les contributeurs du GSoC pour être sûr que le travail correspond bien à ce qui est attendu, et c'est autant de temps pris sur le développement au sein de l'équipe. Le regrettable épisode raté du travail payé par financement participatif (voir https://linuxfr.org/news/dernieres-evolutions-autour-de-0-a-d--2#am%C3%A9lioration-des-performances-et-campagne-de-dons ) n'a fait que confirmer les doutes des développeurs : les grosses contributions de fond, lorsqu'elles sont faites par un contributeur externe, nécessitent une vigilance et un investissement trop important. C'est pourquoi pour le pathfinder ils ont préféré avoir des membres de l'équipe de développement, qui connaissaient bien le code et à qui ils pouvaient faire confiance pour produire ce qui était attendu. J'imagine que ce serait pareil pour un travail avancé sur le multithreading.
*splash!*
[^] # Re: gz
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Oui, l'intégration de gros bouts de code écrits par un codeur externe (et qui potentiellement ne va pas continuer par la suite) est souvent problématique ; sur Blender par exemple on voit souvent des GSoC n'être intégrés que des années après. J'ai donné pour le financement participatif, et je suis donc forcément déçu par ce qui s'est passé ; mais on peut aussi voir les choses sous un autre angle et voir ces grosses contributions comme des "Proofs of concept", et qui permettent d'infirmer/confirmer que certains développements valent le coup (ou pas). Potentiellement, il auraient été trop risqué qu'un core dev passe du temps là dessus sans savoir à quoi s'attendre, donc au final ça n'est pas fondamentalement négatif (mais l'équipe de 0AD fera bien ce qu'elle voudra, bien évidemment).
# Au moment de la publication, j'étais en train d'y jouer !
Posté par PolePosition . Évalué à 3.
Je faisais une pause, et ai checké Linuxfr.org, entre deux défaites contre l'IA…
Putain ils sont trop fort les adversaires IA !
C'est mon premier jeux… J'aime bien, mais le fait de tout le temps perdre commence à me frustrer… :-/
[^] # Re: Au moment de la publication, j'étais en train d'y jouer !
Posté par tipic . Évalué à 2. Dernière modification le 22 janvier 2016 à 18:29.
Très juste.
Soit ils sont très fort, …soit je suis nul !
Je ne sais pas que dire, mais je pense que l'IA est très fort. Je ne sais pas pourquoi, mais ça m'énerve… :-)
Bon l'avantage est que cela fait travailler les méninges.
[^] # Re: Au moment de la publication, j'étais en train d'y jouer !
Posté par PolePosition . Évalué à 5.
Ma "stratégie" est la suivante :
- les femmes vont au champs,
- je fais naître environ 10 hommes le plus vite possible afin de les mettre au travail et d'avoir des ressources matérielles,
- je crée un entrepôt près des ressources (bois, etc) afin qu'ils évitent d'avoir à faire de longs aller-retour,
- je clique là où il faut sur l'entrepôt pour que les outils soient plus efficaces,
- ce n'est qu'ensuite que je crée une Caserne et là je crée des dizaines de Cavaliers super vite.
Sur les maps où il y a de l'eau, je crée des murs en bois, ça empêche fortement l'ennemi de passer, c'est super efficace.
De plus, les tours avec une Sentinelle dedans ça aide parfois (selon la maps et la présence de mur en bois ou non).
Mais parfois, j'ai à peine le temps de créer la Caserne que l'ennemi vient avec des Chars en bois….
Ils sont hyper rapides !
Quelle est ta stratégie ?
J'ajoute que je débute, donc pas se moquer de moi tu dois !
[^] # Re: Au moment de la publication, j'étais en train d'y jouer !
Posté par eingousef . Évalué à 6.
Tu peux choisir entre différents niveaux d'IA dans l'écran Match Setup.
*splash!*
# Crédits
Posté par eingousef . Évalué à 8.
Les animation des algorithmes de pathfinding sont issues de Wikimedia Commons et sont sous CC by 3.0 :
https://en.wikipedia.org/wiki/File:Dijkstras_progress_animation.gif
https://en.wikipedia.org/wiki/File:Astar_progress_animation.gif
*splash!*
# Intéressant
Posté par Nibel . Évalué à 3.
Très intéressant ce point de vue. J'ai participé un tout petit peu à la traduction et c'est sympa de voir comment ça se passe en interne, sachant que je ne suis pas régulièrement leurs forums.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# Dedoimedo
Posté par macadoum . Évalué à -10.
PAs mal comme blogueur, il des choses juste sur Firefox. J'avais quitté firefox pendant longtemps pour Palemoon jusqu'à ce que ce dernier décide de casser presque toute compatibilité avec les plugins de firefox. Du coup je de nouveau dessus, désabusé.
# Algorithmes génériques
Posté par damiend . Évalué à 5.
Ne serait-il pas possible de faire une (des ?) bibliothèque générique pour tout ce qui relève d'algorithmes de chemins, de théorie des graphes, etc. optimisée et diversifiée (choix d'algos) au maximum, et l'intégrer aux dépôts, de façon à pouvoir simplement la mettre en dépendance de son projet et utiliser les meilleures solutions disponibles ?
Ce problème revient à chaque fois qu'on développe un RTS (comme confirmé ici), et il touche de nombreuses autres questions dans des domaines très divers (gestion d'emplois du temps, partage des tâches, optimisation multivariables… gestion de paquets d'ailleurs…).
Cela rendrait des solutions complexes facilement accessibles.
[^] # Re: Algorithmes génériques
Posté par n0wic . Évalué à -8. Dernière modification le 23 janvier 2016 à 18:02.
Alors je dis peut-être une bétise mais ce que tu cherches pourrait être ca : http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ewhat-is-mt.html abordé durant un mooc de la FUN : https://www.france-universite-numerique-mooc.fr/courses/Strasbourg/17001S02/session02/about (bonne chance pour le diplôme et les débouchés)
en gros une compilation d'algorythmes qui peut etre implémentée dans dans des programmes en différents langages.
Et comme tu as accès aux sources tu peu voir tous les algo dans ton langage ce qui est plutot très instructif.
Seulement la différence c'est que ton implémentation dépend du code qu'il y a autour et donc c'est aussi simple d'implémenter un algo unique avec des paramêtres optimisés pour ton application.
La meilleure solution c'est toujours celle que tu as choisies je ne t'encourrage pas à réinventer la roue mais ca donne plus de maitrise sur ton travail au final.
Ou alors est-ce que tu cherches est plus axé sur la représentation ?
[^] # Re: Algorithmes génériques
Posté par damiend . Évalué à 1.
Un générateur de nombres aléatoires en C ? Je vois pas trop le rapport désolé :x ni de compilation d'algorithmes dans ce lien.
Quant à la dépendance au contexte et au format des données, tu as raison en effet ; je m'en suis rendu compte en y repensant tout à l'heure x)
Le simple passage en paramètres semblant inenvisageable (trop de données à copier), je vois deux solutions :
un genre de format standard d'organisation dans la mémoire / les noms de variables / autres. Mais c'est compliqué d'envisager un truc suffisament générique. Mais on peut faire plusieurs standards…
un paramètre (chaîne de caractères spéciale par ex.) indiquant la forme en mémoire des données que l'on a. Ce qui me semble faisable et beaucoup plus logique.
Tu ne m'apprends rien x) Mais je crois justement qu'on devrait résoudre ce problème de façon pérenne : quand je parlais d'accessibilité, je pensais notamment au fait que programmer ce genre d'algos n'est pas à la portée de tout le monde. De fait, cet article…
[^] # Re: Algorithmes génériques
Posté par Vincent Knecht . Évalué à 3. Dernière modification le 26 janvier 2016 à 14:15.
Il y a la bibliothèque Recast & Detour, à priori réservée à la 3D, qui consiste à créer un « mesh de navigation » à partir de l'environnement (la carte) puis effectuer la recherche de chemin…
# Représentation vs réalisme ?
Posté par damiend . Évalué à -3.
Le premier point de la première partie de ce fil.
Je comprends le désir de réalisme, mais est-il besoin d'insister autant là-dessus comme c'est fait dans le jeu ?
Je suggère trois solutions :
1/ Mettre tout le monde à égalité avec aléatoirisation du genre et de la voix des unités, pour tous les types d'unités. Pratique mais pas réaliste (pas forcément problématique, voir en dessous).
2/ Biaiser¹ un peu la sélection des unités pour choisir de représenter davantage des (groupes de) guerrières de l'antiquité ayant vraiment existé. Plutôt réaliste, l'occasion d'apprendre davantage sur l'histoire, possiblement des nouveaux noms d'unités <3
3/ Faire des persos asexués. Solution la plus simple (faudrait quand même s'occuper des voix).
Je pense en fait que représentation et réalisme ne s'opposent pas forcément : en effet, c'est un RTS (fonctionnement militaire et économique), pas une description du fonctionnement sociologique interne des sociétés.
Je ne veux pas te créer du travail en plus, mais ce serait vraiment chouette de s'occuper de ça :) Surtout quand les persos femmes font des petits bruits aussi ridicules -.-" (cela semblait partiellement corrigé dans la dernière version cela dit).
Merci d'avance !
¹ Ce serait acceptable, dans la mesure où le monde est biaisé par défaut dans l'autre sens.
[^] # Re: Représentation vs réalisme ?
Posté par n0wic . Évalué à -3.
Je ne comprend pas bien ce que tu entends par asexués.
[^] # Re: Représentation vs réalisme ?
Posté par damiend . Évalué à 0.
Techniquement, ce serait plutôt "agenrés" en effet :p
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . Évalué à 4.
Les questions sur la gameplay et les décisions de design ne sont pas le sujet de la dépêche, mais je vais juste faire une petite réponse concernant le sexisme :
0 A.D. tente d'être proche de la réalité historique et le gameplay et la partie artistique en dépendent plus ou moins lourdement. Notamment, la table des unités dans chaque civilisation est lourdement inspirée de la structure des civilisations "centrales" de la méditerranée, à savoir les civilisations grecques et romaines, à cette époque. Ces civilisations étaient extrêmement sexistes dans leur fonctionnement, les femmes et les hommes avaient chacun une place qui leur était réservée (notamment seuls les hommes faisaient la guerre, avaient un service militaire obligatoire, les femmes étaient cantonnées à certains métiers civils, etc.). Cela se reflète dans le jeu par la séparation entre deux types majeurs d'unités : les citoyennes et les citoyens-soldats. Les citoyennes ne peuvent effectuer que des activités économiques (ramasser des ressources et construire des bâtiments civils), alors que les citoyens-soldats peuvent exécuter toute activité économique ou militaire. Il existe une troisième catégorie majeure d'unité : les champions, qui ne peut effectuer que des activités militaires (et qui correspond historiquement à la progression d'une armée de citoyens mobilisés vers une armée de métier).
Le concept en lui-même ne me paraît pas déconnant, si c'est pour des questions de réalité historique, pourquoi pas. Par contre il y a des choses que je ne m'explique pas :
Pourquoi conserver le même paradigme pour les civilisations non basées sur la culture gréco-romaine ? Une organisation sexiste peut se comprendre pour les Athéniens, les Macédoniens, les Spartiates (encore que dans leur cas les citoyennes peuvent se battre et construire des palissades), les Romains, les Égyptiens, les Séleucides, probablement aussi les Carthaginois (très proches des grecs et des romains culturellement), peut-être aussi les Perses (même s'il y a eu au moins une femme dans les rangs des officiers perses, mais peut-être s'agit-il d'une exception), à la limite les Maurya (il y a eu des femmes dans l'armée maurya, mais celles-ci sont présentes dans le jeu via une catégorie de champions, les maiden guard), mais pourquoi garder la même organisation pour les peuples Celtes, réputés non-sexistes ? Je ne pense pas que les développeurs aient envie de complexifier le jeu en retirant le mécanisme citoyen-vs-citoyens-soldats pour les Celtes, mais il n'y a pas vraiment de raison à ce que les citoyens et les citoyens-soldats n'aient pas des variations mâles et femelles en égales proportions, à l'image des soldats Elfes et Hors-la-loi de Battle for Wesnoth, à part peut-être la charge de travail artistique supplémentaire.
Pourquoi ne pas faire des unités mâles similaires au citoyennes en terme de compétences ? À ma connaissance même dans la société grecque il y avait des hommes qui ne combattaient pas (des esclaves notamment). (En plus je viens de voir un truc : c'est d'autant plus vrai dans la société de la république romaine : il était très rare que des femmes labourent les champs, les matrones étaient exemptes de tâches agricoles et laissaient cela à leurs esclaves)
Pourquoi n'y a-t-il pas de mixité dans les unités de support autre que les citoyennes ? Les prêtres sont soit tous mâles (Grecs, Romains, Égyptiens, Séleucides, Celtes, Perses, Mauryas), soit tous femelles (Carthaginois, Ibères). Les marchants et pêcheurs sont toujours mâles. Alors qu'il y avait des femmes prêtres chez les Romains, les Égyptiens, les Celtes et les Mauryas, et des hommes prêtres chez les Ibères (je ne sais pas trop pour les Grecs, les Perses et les Carthaginois, il faudrait vérifier). Et les femmes exerçaient la pêche ou les métiers de commerce à peu près partout je pense.
Bref, j'ai un peu du mal à tout comprendre. Surtout pour les Celtes.
Tu parles à qui ?
*splash!*
[^] # Re: Représentation vs réalisme ?
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C’est juste mon avis, mais je trouve l’idée de la distinction homme/femme passionnante, évidemment ça complexifie énormément les choses mais c’est ça qui est passionnant, et c’est ça aussi qui donne de la saveur à ce jeu je trouve. À force de faire du neutre et échangeable on obtient des choses sans saveur. Après il faut faire cela bien. Je ne connais pas bien ces civilisations mais oui on peut donner l’exemple des vestales ou des rôles comme cela, je n’ai pas envie de voir ce rôle attribué à un homme dans 0ad. Pour le moment elles ne sont pas là, mais à mon avis il vaut mieux pousser vers leur inclusion plutôt que vers un affadissement.
Ce n’est pas dans la période historique couverte par 0ad, mais par exemple au moyen-âge les femmes avaient un très grand rôle et faisaient jeu égal avec les hommes ou les surpassait bien des fois (comme quand certaines mères abbesses de monastères avait une autorité seigneuriale et un rôle politique et diplomatique bien plus grand que certains de nos chefs d’états aujourd’hui, sur des grands territoires…). Par exemple s’il y avait un plug-in 0ad pour le temps des croisades, je trouverais cela excellent de mettre les hommes loin au combat (et incapable d’administrer son propre royaume), en ne permettant qu’aux femmes d’administrer et développer le royaume, parce que c’est juste la réalité, à cette période, les hommes étaient juste des bons-à-se-battre et des grands-absents pendant que les femmes étaient chef d’état. Il y a certainement plein de choses comme cela dans l’antiquité, ça serait vraiment excellent.
Le post d’Organix cité par damiend< s’inquiète du sexisme de voir la femme aux champs, mais en même temps n’hésite pas à proposer « Female citizens who can fight and build military buildings ; only workers of the game. Men are devoted fighters.» et « Soldiers must be constantly in a "search & destroy" mode, not in grape picking. », ce qui est tout aussi sexiste, comme le font remarquer d’autres personnes dans la discussions.
Ce qui est bizarre dans 0ad ce n’est pas que dans telle civilisation antique la femme travaille surtout aux champs et l’homme serait un militaire de métier (eh, dans l’armée romaine, le service militaire est uniquement masculin, d’ailleurs, dans certains cas, il était interdit aux soldats de se marier, ce qui exclut même la “femme du soldat” !), mais que la femme n’ait pas plus de pouvoir de construction de la cité justement. Il y a plein de bâtiments dont la construction ne peut être initiée que par des hommes, et on pourrait imaginer qu’au contraire, si certains bataillons d’hommes surentraînés ne peuvent pas cultiver, et bien les hommes ne pourraient pas initier la construction de bâtiments clés de la cité, notamment ceux nécessaires aux “phases” civilisationnelles, et tout plein de choses comme les merveilles, les marchés, les temples, les théâtres, les palissades, et les centre-villes, cela pouvant varier selon les civilisations, voire le donner exclusivement aux femmes parfois. On peut imaginer par exemple que dans certaines civilisations seules les femmes peuvent fonder un nouveau centre-ville (ce qui est une action stratégique énorme) mais que seul les hommes peuvent initier la construction d’une caserne. En fait tout le monde peut déjà participer à la construction, la question c’est : « qui décide ? ». Je trouve ça super passionnant. En fait on pourrait même laisser aux femmes la décision de construire la caserne qui produit des hommes soldats incapable de cultiver la terre ou de construire quoi que ce soit, ce qui humilierait l’homme qui ne serait que de la chair à canon. Bref, ça aussi c’est sexiste et je crois qu’on s’en fout, ce n’est pas un jeu qui se passe dans un fantasme de futur utopique androgyne et sans saveur.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . Évalué à 3.
Le gros problème quand on ramène ce sujet sur la table, c'est qu'on mélange très vite des trucs qui n'ont rien à voir, à savoir l'opposition citoyens vs citoyens-soldats, qui est une question qui se pose uniquement sur le plan du gameplay, et l'attribution d'un genre spécifique à une catégorie d'unités, qui est une question qui se pose purement sur le plan artistique. C'est complètement hors-sujet, je regrette déjà d'avoir écrit mon commentaire précédent.
*splash!*
[^] # Re: Représentation vs réalisme ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
moi de même parce que je sais que je n’aurai ni le temps ni la force de répondre à toute surenchère sur le sujet. ^_^
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Représentation vs réalisme ?
Posté par Jiel (site web personnel) . Évalué à 3.
Pas les Égyptiens. Les Égyptiennes pouvaient être juge, gouverneur, général et même chef d'état ; elles pouvaient aussi être indépendantes et avaient souvent le contrôle sur la bourse de la maison. Cela choquait d'ailleurs énormément les Grecs de rencontrer des femmes soldats. Le modèle « femme à la maison » est très greco-romain.
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . Évalué à 3.
Même pendant la période ptolémaïque ?
*splash!*
# Désync multiplayer
Posté par EauFroide . Évalué à 3. Dernière modification le 25 janvier 2016 à 23:33.
Je viens d'essayer une Lan avec un pote et je désynchro a tout bout de champs, est-ce normal? (j'apprécie le fait qu'on peut quitter et reprendre une partie en cours d'ailleurs, se fut salvateur!)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Désync multiplayer
Posté par eingousef . Évalué à 4. Dernière modification le 26 janvier 2016 à 12:08.
Une OOS ? Ça arrive assez souvent. Vérifie bien que vous utilisez tous les deux exactement la même version (qu'il n'y en ait pas un sur l'a19 et un autre sur la version svn, par exemple), et fais un ticket de bug, parce que c'est le genre de bug pas facile à détecter. Il est possible qu'on te demande d'envoyer ton commands.txt et d'autres fichiers de logs qui pourraient avoir été générés par le jeu suite à l'erreur.
*splash!*
[^] # Re: Désync multiplayer
Posté par EauFroide . Évalué à 1. Dernière modification le 26 janvier 2016 à 13:06.
OOS? ché quoi?
On est tout les deux sur la dernière version (19, syllepsis) installé via
sudo add-apt-repository ppa:wfg/0ad
sudo apt-get update
sudo apt-get install 0ad
Les 40 premières minutes ont bien tourné puis arrivé à un certain moment j'ai du régulièrement quitter/rejoindre la partie car ce qu'il se passait a mon écran différait de l'autre personne (exemple un ennemi a débarqué, à mon écran mon armée s'est fait poutrer et l’ennemi s'attaque à mon avant poste alors qu'à l'écran de l'autre personne (qui héberge la partie), on a gagné la bataille depuis longtemps).
Je vais essayer de reporter plein de bugs sur 0ad mais je suis nul avec l'anglais :P
En passant, mon ami m'a demandé a plusieurs reprises comment DÉTRUIRE un batiment plus tôt que de le prendre, sans obligatoirement utiliser d'arme de siège.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Désync multiplayer
Posté par xcomcmdr . Évalué à 3.
Out Of Sync ? (désynchronisation)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Désync multiplayer
Posté par eingousef . Évalué à 2.
Ouais, voilà. Un exemple de ticket : http://trac.wildfiregames.com/ticket/3637
*splash!*
[^] # Re: Désync multiplayer
Posté par eingousef . Évalué à 2.
Ctrl + Clic droit ?
En passant il devrait y avoir un item "Apprendre à jouer" dans le menu principal avec toutes les commandes par défaut.
*splash!*
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.