Antoine a écrit 5722 commentaires

Tiens, c'est le login qui s'affiche à la place du nom maintenant ? m'enfin...

Hello,

Bon, comme j'ai été actif dans le projet l'autre net un bout de temps au début, je suis bien placé pour répondre ;)

Sur les problèmes d'autogestion et de non-respect des règles édictées au départ, tu as effectivement raison.

Pour Meyssan, c'est n'importe quoi. D'abord le terme "nazi rouge" est ridicule et confine au point Godwin ainsi qu'à la diffamation ; d'ailleurs, Meyssan est membre du "parti radical de gauche" (PRG), qui est assez loin d'être extrêmiste. Ensuite, il n'y a aucune raison qu'il soit lié à lautre, 1) parce que ça ne lui apporterait rien (lautre n'a politiquement aucun intérêt, techniquement très peu, et Meyssan ne s'intéresse pas à la technique), 2) parce que socialement il y a de fortes chances que ça ne marche pas du tout vu les types de personnalités en jeu.

Amicalement

Antoine.

Allez, rêve pas ;) Le BVP, une invention des publicitaires qui sont seuls à y siéger n'est qu'un machin fantoche destiné à tromper les médias (consentants à mi-mot, vu que la majorité vivent de la pub et de l'illusion consumériste....) et les bonnes âmes. En même temps qu'ils laissent passer les pubs plus connes, nulles et réacs (pléonasme ou presque), le BVP a censuré un spot d'Amnesty International contre la Chine, entre autres faits d'armes. C'est comme si la Convention Européenne des Droits de l'Homme n'acceptait en son sein que des tortionnaires.

En toute rigueur, la notation O(...) définit le nombre d'opérations nécessaires à une machine de Turing, pas le temps mis pour résoudre le problème. Cela veut dire par exemple que si tu considères une machine parallèle, les temps peuvent diminuer à O(...) constant. Cf. les récentes avancées en matière de cassage de RSA par Bernstein. Celui-ci n'a pas diminué la complexité algorithmique (vis-à-vis d'une machine de Turing), mais le temps mis par une machine "réelle" pour effectuer ces opérations.

Ouhla ! On ne sait pas que NP-complet veut dire "non polynomial". Qui sait, peut-être dans quelques années quelqu'un démontrera que P=NP...

Si on veut du O(n*log(n)) en pire cas, on peut prendre un heapsort (tri par arbre). En plus, c'est un algo très mignon. On construit un arbre particulier de taille n dont la racine est toujours le plus élément de l'arbre. On extrait cette racine, on la place à la fin du tableau et on recommence avec l'arbre taille n-1. A chaque itération, la réorganisation de l'arbre prend O(log(k)), ceci n fois donne O(n*log(n)).

Le quicksort est en O(n*log(n)) dans le meilleur cas justement (et on espère que par un choix judicieux on arrive à s'en approcher statistiquement). Le pire cas est bel et bien en O(n*n) : ainsi si chaque découpage te conduit à avoir un sous-tableau de un élément et un sous-tableau de (k-1), alors le tri dégénère et devient équivalent à un tri à bulles.

J'oubliais qu'il faut des gens pour tester le jeu. Non pas simplement des gens qui jouent (ça c'est facile à trouver ;-)), mais qui soient capables de déceler, d'expliciter et de recenser exhaustivement les problèmes liés au gameplay, à la facilité d'utilisation, les bugs, tout cela avec la vision du joueur moyen (encore une fois, même problématique que pour les environnements graphiques : savoir se mettre à la place de l'utilisateur final). Testeur est un métier à part entière dans l'industrie du jeu (et c'est moins amusant qu'on ne le croit...).

Je ne pense pas que l'effectif de l'équipe soit le problème principal. C'est plutôt le mode de développement. Un jeu video, ça touche à la création artistique (au sens large), la façon qu'on a de juger un jeu n'est donc pas du tout la même que pour un serveur Web par exemple. Un jeu et son gameplay forment un tout, un élément mal conçu rejaillit négativement sur l'ensemble du jeu (par comparaison, une fonctionnalité mal codée dans un utilitaire n'obère pas le reste des qualités du soft : il suffit de ne pas utiliser la fonctionnalité mal codée).

D'autre part, un jeu a besoin d'une ligne directrice et d'une cohérence forte. Il faut avant tout qu'il y ait deux ou trois personnes ayant une vision d'ensemble précise de ce qu'ils veulent faire (gameplay, graphisme, programmation), et aussi que le reste de l'équipe soit prête à suivre les exigences de ces personnes-là. Pour prendre une analogie peut-être douteuse, tu ne remplaces pas un romancier de talent par une dizaine de journalistes travailleurs (par contre ils peuvent faire un très bon journal). Et on commence à toucher les limites du développement type bazar : en général les gens y rechignent à accepter un leadership, surtout s'il se base sur des critères extra-techniques qui peuvent sembler arbitraires. On n'aime pas être commandé dans un travail bénévole.


Le mode de développement dans les boîtes de jeu s'apparente de plus en plus à celui de l'industrie du cinéma. Tout part d'un premier jet lancé sous la forme d'idées graphiques et scénaristiques (synopsis, dessins au trait et au crayon...). On recense les différentes caractéristiques du jeu, que ce soit au niveau du gameplay, de l'ambiance, des besoins techniques. Une charte graphique et une charte technique sont constituées, et des exemples peuvent être réalisés rapidement comme "proof-of-concept". Ensuite on affine progressivement en commençant réellement à implémenter certaines choses, certains éléments graphiques par exemple (meshes, textures, sprites...), et les briques de base au niveau technique. La suite est plus classique, une fois que les besoins sont clairement définis. Mais le but est toujours d'avoir des résultats évaluables le plus tôt possible (même s'ils sont très parcellaires), afin de juger de la validité du concept. Par exemple, avoir un premier niveau qui tourne est très important.


Bon, pour répondre quand même à la question, côté effectif, un jeu "moyen" (en termes de budget) tourne à une dizaine de personnes pendant un an. Disons quatre programmeurs, quatre graphistes, deux game-designers. Ca dépend bien sûr du type de jeu, de la quantité de briques de base existantes et réutilisables, du temps que tu te donnes. Warcraft 3, si tu regardes le générique de fin, c'est autre chose : ils ont vraiment mis le paquet ! Mais c'est à cause de l'extrême finition graphique, scénaristique et sonore. Comme le suggère quelqu'un d'autre, un jeu comme Warcraft 2 doit être assez abordable pour une équipe bénévole. Note, il faut faire bien attention que les phases de réglage, débuggage, mise au point risquent d'être longues (même problématique que pour un environnement graphique : on veut un résultat très fignolé, très cohérent ; pas question d'accepter une juxtaposition de bidouilles disparates).

(petit aparté à propos de Warcraft 3 : ils ont eu l'excellente idée de réaliser la plupart des séquences non-interactives en 3D temps réel, et en utilisant les mêmes modèles que pour le jeu lui-même. Du coup, même si c'est moins léché que les vidéos précalculées, ça a dû leur épargner un paquet de travail graphique et cinématique. Une voie à suivre à mon avis, surtout que ça épargne également les ressources soft et hard nécessaires à de telles cinématiques).


Pour terminer, je dirais qu'un exemple de projet qui me semble avoir un mode de développement adapté à un jeu vidéo est... F-CPU. Il y a une ligne directrice claire (même si apparemment elle a pris du temps à se dégager ;-)), une personne - YG - a une vision d'ensemble complète, très précise voire autoritaire, et quelques contributeurs talentueux sont prêts à suivre cette vision même si c'est parfois au détriment de leurs propres opinions spécifiques. Et, bien qu'ils soient une petite équipe au regard de la tâche entreprise, ils avancent progressivement.


PS : - Je précise que je n'ai jamais eu aucune responsabilité dans la supervision d'un jeu ;-))

- Pour le son on peut sûrement se contenter de la contribution relativement ponctuelle d'une personne spécialisée dans le domaine.

J'ai bossé chez Cryo y a quelques années. Effectivement beaucoup de programmeurs viennent (venaient ?) du monde de la démo et de la bidouille autodidacte. Ca pose beaucoup de problèmes pour faire adopter des stratégies de développement saines et viables. Par exemple, il y a des coders qui refusent absolument de toucher à du C++ ; c'est pas qu'ils comprennent pas, non, c'est que c'est le Mal incarné par rapport au C qu'ils sont habitués à coder (et c'est du C plutôt bas niveau, genre j'optimise la moindre multiplication en la transformant en décalage à gauche, même si ce n'est pas dans un chemin d'exécution critique). Il y a en aussi qui ne veulent pas travailler avec des outils génériques, parce que ce ne sont pas eux qui les ont faits, et ils vont faire perdre des mois au projet en recodant un moteur customisé, qui finalement est moins bien foutu que le générique car le gars s'est concentré sur l'optimisation bas niveau au lieu de réfléchir à une conception intelligente et à des algorithmes efficaces.

Dans le jeu sur lequel je bossais, on utilisait le moteur 3D de la boîte (entièrement en C++, massivement templatisé, vraiment belle conception et performances honorables) et la STL faisait partie des outils recommandés ; néanmoins sur les cinq programmeurs il y en avait deux qui n'utilisaient pas la STL mais leurs propres fonctions (pourries) de gestion de listes, et qui n'utilisaient pas les types intégrés au moteur 3D mais leurs propres types pour les objets géométriques (bonjour les conversions). Les deux programmeurs étaient, je te le donne en mille, des demomakers. Pour la petite histoire, le jeu n'est jamais sorti, en grande partie à cause du management exécrable de Cryo, mais aussi des problèmes de délais.

Tout ça fait qu'à mon avis, en milieu hobbyiste où il y a peu de leadership, le développement d'un jeu peut se transformer en désastre en termes de perte de temps et de conception ratée. Bien sûr, ce n'est pas une généralité.

Non, non, faut pas déconner. T'as lu un forum du FDI ? Ton professoral de l'expert qui se pose, messages dilués dans des tournures prétentieuses et vaines, intérêt intellectuel proche du zéro absolu. Sans compter que les "experts" qui s'y expriment au milieu des internautes ne sont pas spécialement réputés pour leur connaissance du Réseau. Et comme réservoir à idées, heu, pardon, on y retrouve les mêmes discussions qu'il y a des années sur n'importe quel site parlant du sujet, avec en plus la petite couche de respectabilité feutrée de rigueur dans les salons où l'on discute entre gens qui se comprennent.

La news ci-dessus est un vrai panégyrique idiot du FDI. Par curiosité, j'ai fait une recherche sur le nom de l'auteur, il a pas l'air très connu. En fait :

http://www.google.com/search?q=%22Jean-Louis+Fandiari%22&hl=fr&(...)

Les seules occurences où son nom figure sur la toile, c'est en compagnie de ceux de Lionel Thoumyre et Benoît Tabaka. Lionel Thoumyre est salarié en tant qu'animateur par le... Forum des Droits sur l'Internet. Benoît Tabaka est (ou fut) président de l'ADIM (Association des Internautes Médiateurs, coquille vide qui se veut représentative auprès des politiciens et décideurs), association qui fut l'un des premiers membres du... Forum des Droits sur l'Internet. Amusant non ?


Pour la petite histoire à propos des discussions "de haute volée" (hou hou), un thread mémorable qui parlait des liens hypertextes a été animé par quelques pseudonymes farceurs issus d'uZine. Le plus marrant, c'est que les tirades à pisser de rire sur le danger des "dead links" et autres "trash links" ont été prises au sérieux par les membres du FDI. Bravo les experts.

Y a carrément un trou de sécu aussi : http://bugzilla.mozilla.org/show_bug.cgi?id=166218

Tiens, oui, je sais pas pourquoi j'ai posté ça ici... Besoin de sommeil je crois ;)

-1

J'ai essayé de reproduire le bench indiqué en page d'accueil. Installé le bidule, activé le cache. Malgré tout, sur un bi-P3 1 GHz, je n'arrive "qu'à" 180 requêtes/s. Je ne sais pas comment vous arrivez à 400 requêtes/s sur un P2 400... Quelque chose de spécial dans la config Apache/PHP ?

(notez, c'est quand même pas mal du tout comme niveau de performances ;-))

C'est surtout qu'elle serait complexe. Le langage des templates permet d'utiliser des critères grosso modo équivalents à des critères SQL (de type WHERE) pour spécifier quelles données affichées. De plus, SPIP ajoute certains mécanismes particuliers (du genre : une rubrique n'est visible en public que lorsqu'elle contient au moins un article, ou une brève, ou une sous-rubrique elle-même visible...). Ca me paraît particulièrement ardu à traiter, et bonjour les bugs.

(note : je pose en plusieurs fois, je n'arrive pas à poster de gros messages)

En fait, le problème c'est que ces dépendances ne sont pas figées mais définies par les templates (squelettes) réalisés par le webmestre. Une analyse systématique des dépendances serait trop lourde. On a fait un compromis pour les forums : on y analyse les dépendances les plus communes.

Question de simplicité. Recalculer la page d'article quand un article a changé ne pose pas de problème. Mais imagine :

- il faut aussi recalculer la page consacrée à la rubrique contenant l'article
- il faut éventuellement recalculer la page consacrée à la rubrique parente, si le webmestre y affiche les articles des rubriques filles
- il faut éventuellement recalculer la page des mots-clés liés à l'article, des articles liés aux mots-clés à l'article
- etc.

C'est un test à faire mais entre .html et le cache de SPIP telle qu'il est, on doit pouvoir multiplier les perf par 2 ou 3 mini et voir beaucoup plus.

Exact. Une page en cache sous SPIP prend 10 à 20 ms (mesuré avec ApacheBench). C'est probablement 10 fois plus qu'une page statique.

(désolé de ne pas faire de réponse plus longues, le serveur me jette :-(( )

"trucNuke" s'appelle en fait PhpNuke (voir www.phpnuke.org) et en est à sa version 6.0 je crois.

Plus exactement, il y a l'original et une nuée de forks qui s'en sont suivis (et ça continue...). Pour un aperçu de la galaxie des Nuke-like, voir le site http://www.kaintech.net/.(...)

Personnellement si j'avais besoin de fonctionnalités de type communauté, je prendrais plutôt daCode : code propre, système de cache, et système de votes/modération très sympathique. Les *-Nuke pour moi, c'est vraiment la foire aux machins en tout genre, c'est un gigantesque gloubiboulga incontrôlable et préhistorique.

Bon, après l'avoir utilisé un petit peu à la place de l'ancêtre, je trouve que les réglages par défaut sont trop intrusifs. Un exemple, il filtre tous les pop-ups même ceux ouverts par un lien HTML, ce qui fait foirer les fenêtre de vote de Linuxfr. Aussi, certaines images sont filtrées uniquement à partir de leur taille, ce qui vire aussi les bandeaux non-publicitaires....

Cependant tout ça est configurable même si le truc n'est pas immédiat (il y a différents groupes d'actions associés à différents types d'URLS, et un groupe d'actions par défaut qui est celui à modifier).

D'autre part c'est vrai qu'avec les fonctionnalités de Mozilla l'outil perd un peu de son intérêt (notamment pour les cookies).

(désolé pour les sauts de ligne, semblerait que le <pre> bugge un peu ;-))

Pour ceux que ça intéresse, sous SPIP, on ne s'est pas trop fait chier... Voici le bout de code :

function feed_globals($table) {

	if (is_array($GLOBALS[$table])) {

	        reset($GLOBALS[$table]);

	        while (list($key, $val) = each($GLOBALS[$table])) {

	                $GLOBALS[$key] = $val;

	        }

	}

}



feed_globals('HTTP_GET_VARS');

feed_globals('HTTP_POST_VARS');

feed_globals('HTTP_COOKIE_VARS');

feed_globals('HTTP_SERVER_VARS');

Mignon non ;))

(http://rezo.net/spip-cvs/ecrire/inc_version.php3?rev=1.87&cvsro(...))