rewind a écrit 3425 commentaires

Comme quoi les inquiétudes sur le biais en faveur d'Upstart dus à la présence d'employés Canonical n'était pas complètement fondés.

Ou si. Tous les employés Canonical ont voté en bloc pour Upstart, ou du moins pour barrer la route à systemd. Dans quelle autre distrib communautaire s'est-on posé la question d'Upstart à ce point ? Aucune. Et ça, ça vient bien du fait qu'il y ait des employés Canonical dans le ctte.

son commentaire était tout a fait pertinent

Tellement pertinent qu'à l'heure où j'écris, il est à 0. Comme quoi je ne dois pas être le seul à avoir réagi de cette façon.

Ma boutade n'est pas sur le fond mais sur la forme. Tu admettras quand même que Zenitram est un peu culotté de dire qu'il ne lit pas l'article mais après, il va faire 50 commentaires dont celui auquel je réponds. Mais à propos de quoi puisqu'il ne lit pas l'article ? Donc, je fais comme lui, je vais me permettre de critiquer mais je ne vais pas lire ce qu'il écrit. Il ne m'en voudra donc pas. Il aurait pu expliquer ce que tu dis, calmement et ça serait sans doute mieux passé.

Posté par Zenitram

Poubelle. Pas de lecture plus loin.

Quand tu dis qu'il faut être indulgent sur le code, je trouve que tu te dévalorises beaucoup. Tu as le style d'un développeur Java (du coup, tu utilises un sous-ensemble de C++), mais ça fonctionne très bien, le code est très compréhensible.

ça implique quand même de devoir réécrire tout un tas de trucs… chez Go, pour les changements de nom dans la lib standard, ils avaient développés un outil pour faire les modifications automatiquement, on en est loin là !

laisse aux développeurs de Rust le soin de choisir quand ils considèrent que le projet est suffisamment cohérent et propre pour être stabilisé.

On ne peut pas dire que ce n'est pas stabilisé et en même temps qu'il faut l'utiliser. Or, c'est exactement ce qui est dit à la fin :

Il y aura encore sûrement des changements dans la syntaxe — et dès la parution du la version 0.9, il y en a déjà, voir This week in Rust du 11 janvier — mais le langage est très proche de la complétion et il commence à y avoir suffisamment de ressources en ligne pour apprendre. Il n’y a plus d’excuses pour ne pas se mettre au Rust ! ;)

Pour moi, c'est incohérent ! Et je préfèrerais qu'ils disent : «OK, il va y avoir des changements de syntaxe importants, on va attendre d'avoir tout remanié et ensuite, on appellera à des tests et si pendant suffisamment de temps, on n'observe pas de besoin de nouveaux changements de syntaxe, on décrétera que c'est figé.»

Java, C, C++ sont dans la première catégorie. Python est à la limite (parce qu'il y a un processus pour normaliser). Donc, je choisis cette catégorie là. Surtout que donner Visual Basic comme exemple du second, je trouve ça particulièrement croustillant, ça donne vraiment envie !

Bon, si on arrête de rigoler deux secondes, tes catégories n'ont aucune signification, il y a des bons et des mauvais langages dans les deux (sous-entendu, des langages pour faire des choses utiles). Et ce n'est absolument pas la question que je pose. Je m'étonne qu'un langage qui a déjà un historique assez long et qui est plutôt sur la voie de la finalisation soit encore si instable au niveau de sa syntaxe. Si on prend Go par exemple, il a convergé petit à petit et les changements de syntaxe ont été de moins en moins invasifs jusqu'à la version 1. Là, on change un des trucs mis en avant depuis le début !

Si on voulait faire un parallèle, on prendrait plutôt les clichés dans les romans. Par exemple, quand tu prends 90% de la littérature de médiéval fantastique, c'est uniquement du cliché vu et revu. C'est lassant, et c'est ça qui est dénoncé. Maintenant, ça ne veut pas dire qu'un énième titre de médiéval fantastique rempli de clichés ne marchera pas.

Il n'y a que moi qui trouve inquiétant qu'un langage qui est en développement depuis plusieurs années et qui s'approche de la version finale à grand pas soit aussi instable au niveau de sa syntaxe ? (et pas uniquement sur des détails en plus). Moi, quand on vient me dire qu'on peut commencer à tester, je fuis immédiatement, parce que je me dis que ce langage risque d'évoluer suffisamment pour que tout ce que j'apprends et je fais soit obsolète dans deux mois… Enfin, c'est l'impression que ça me donne.

Je m'attendais à ce qu'il prétende que le leveling était sans intérêt.

Le leveling (dans le bon sens du terme) n'est pas sans intérêt, au contraire, il permet au joueur de mesurer sa progression.

Je ne pense pas qu'il dise que c'est mauvais comme gameplay, il dit simplement que le game designer n'a pas fait beaucoup d'effort pour imaginer autre chose que le cliché. Maintenant, il pourrait évoquer le pourquoi (c'est-à-dire pourquoi on voit sans cesse les mêmes clichés), et il l'effleure à peine à deux moments dans la suite de la série. Premièrement quand il parle du turnover, deuxièmement quand il parle des FPS qui sont les nouveaux sidescroller.

Son discours est de dire qu'à cause du turnover, il n'y a pas de mémoire et donc, les game designers refont toujours les mêmes bêtises (ce qui est discutable). Et ensuite, il dit que c'est dans les FPS qu'on retrouve la plupart de ce qu'il dénonce et que ce sont les nouveaux sidescroller, sous-entendu il en existe une tétrachiée qui se ressemblent tous comme les sidescrollers dans les années 90. À mon sens, il analyse bien la conséquence mais il ne voit pas la vraie cause qui est l'industrialisation massive du jeu vidéo. Quand il commence sa série, les «gros» studios sont des nains composés de pionniers, avec une technologie très changeante. Aujourd'hui, on a des entreprises énormes, une industrie qui surpasse le cinéma et la musique, des milliards de brouzoufs à engranger ou à perdre. Donc, comme pour le cinéma, on fait ce qui marche et donc, on ne s'écarte pas trop des clichés et de ce qu'il considère comme des mauvaises conceptions. Je pense qu'il n'a pas vu venir l'industrialisation et sa puissance. Alors oui, actuellement, on voit beaucoup de clones et oui, ça se voit dans les FPS, jeux qui s'adressent à la catégorie qui consomme le plus de jeux vidéos : le mâle trentenaire sans enfant avec une profession intermédiaire ou supérieure.

Dans le même ordre d'idée, il parle beaucoup des sauvegardes, de la manière de faire pour que le jeu vieillisse bien, etc. Bref, des trucs de long terme. Mais ça ne peut plus marcher quand on veut sortir une version par an (avec un delta par rapport à l'année d'avant qui va du minimal au négligeable). Dans ce cas là, on s'en fout de bien gérer les sauvegardes, de toute façon, on en ressortira une version l'année suivante. Ça aussi ça vient de l'industrialisation massive : quelques gros titres tirent le reste des jeux qui marcheront moins bien. Mais sans ces gros titres, le reste aurait du mal à survivre. Pareil que dans le cinéma, ou dans la musique.

Donc, quand il dénonce tout ça, il a raison et tort. Raison quand on se place du point de vue d'un fan de jeu vidéo qui aimerait un peu plus de diversité, mais tort quand on examine les raisons économiques qui poussent à l'utilisation de ces clichés. Quand on développe un jeu amateur (et même indie), on doit écouter ces conseils, pour proposer autre chose, parce qu'on ne pourra jamais rivaliser avec un gros studio sur les clichés.

Au contraire, j'ai trouvé ces articles fort pertinents. L'exemple des caisses est vraiment caractéristique. Certes, c'est fondamental au gameplay, mais pourquoi une caisse ? Pourquoi pas un autre objet ? Tout simplement parce que la caisse est l'objet standard qu'on peut mettre partout, tellement standard que ça en devient ridicule parce que ça n'a souvent aucun intérêt dans le contexte d'avoir une caisse. Plutôt que de chercher quelque chose d'identique niveau forme mais avec une vraie raison, les game designers iront au plus vite.

J'ai beaucoup ri sur un des premiers qui décrit comment les RPG transforment souvent le joueur en marchand d'armes d'occasion. Typiquement ce qu'on retrouve dans beaucoup de MMORPG (et pourtant, l'article original date de 1998). Il y a beaucoup d'autres choses qui sont intéressantes quand on programme un jeu, pour éviter les erreurs. Quand on est joueur, effectivement, on ne se rend pas forcément compte de ce que ça peut représenter.

notamment avec cette histoire d'ombre qui m'a réjoui à la lecture (j'ai vu le cowboy marcher au soleil couchant).

pour l'instant, ça tient du rêve, mais ce n'est pas impossible ;) J'y travaillerai quand j'aurai bien avancé sur le reste.

Je voyais les « tuiles » comme des sprites qui une fois posés sur des ancres s'abuttent (s'il n'y a ni angle, ni offset). J'étais naïvement resté sur la composition de paysage pittoresque avec des petits villages de bric et de broc, ou de capitales avec des quartiers huppés construits en dur et tirés au cordeau avec de grandes allées à statues, contrastant avec des faubourgs plus authentiquement bordéliques, voire bidonvillesques.

En fait, si je comprends bien ce que tu dis, tu voudrais construire des cartes uniquement avec des sprites. C'est une idée très intéressante que j'ai déjà vu utilisé pour des sidescroller. L'avantage, c'est qu'on peut avoir des cartes superbes. L'inconvénient, c'est qu'il faut avoir tout un tas de sprite qui se coordonnent bien, qu'on peut redimensionner comme on veut, et que la construction de la carte est moins facilement automatisable.

Je n'avais pas même pensé aux visites d'intérieur, si ce n'est sous l'angle Zelda*, avec une vue « plan d'évacuation ISO machin bien carrée » décorrélée de l'extérieur (décalage de boussole en option ? moyen de faire des tipis ronds quand même… et des cloisons biscornues ? un must pour une bicoque de sorcière…).

Rien n'empêche d'avoir un jeu de tuiles spécifique pour des bâtiments uniques. Mais bon, ça ne compte pas ;)

Je me suis peut-être mal exprimé, je reprends. Tout d'abord, le jeu est en vue de haut (à la verticale), donc on ne voit vraiment que le haut. Ensuite, la carte est basée sur des tuiles, c'est-à-dire un ensemble prédéterminée de petits morceaux de cartes qu'on va assembler pour construire une grande carte. Et le problème il est bien là, c'est que si tu ne peux pas avoir une quantité monstrueuse de tuiles, pour tous les angles possibles, il faut faire des choix sur ce qui est possible, et dans mon cas, ça sera deux ou trois orientations pour le toit (et ça va déjà faire un paquet de tuiles à faire).

L'autre solution, ça aurait été de poser un sprite (une image) de toit, et là, on pouvait le placer comme on voulait, avec l'angle qu'on voulait. Mais d'un autre côté, il fallait faire correspondre exactement le toit et l'intérieur (sur une autre couche), ce qui n'est pas forcément évident à la main. Il y a également d'autres problèmes que je n'évoque pas. Bref, solution plus flexible mais solution plus complexe.

Sans dévoiler de grands secrets, mes sources actuelles d'inspiration sont :

• Red Blog Games et son magnifique tutoriel
• Procedural Content Generation Wiki

Je vais aller voir tes références pour ajouter des sources d'inspiration.

Merci ! C'est exactement le genre d'exemple que je cherchais. Où je vois donc qu'il a adopté Gettext (ouch, le fichier de 10000 lignes de traduction !), et les chaînes de format de Java (ça, plutôt normal).

Du coup, je me réponds à moi-même pour dire ce que je pense de ces articles. Je pense qu'ils sont tout à fait exact, et je pense que dès le début, je savais que je me lançais dans un projet assez grand. Mais comme je le sais, j'ai pris les devants. Premièrement, j'ai dit que je me donnais deux à trois ans pour finir le jeu, ce qui représente un temps considérable. Ce temps sera vraisemblablement partagé pour moitié dans le codage des mécaniques du jeu, et pour l'autre moitié (voire une très grosse moitié) dans la création de contenu (graphisme, quête, dialogue, etc). Deuxièmement, je prévois de générer un maximum de chose de manière aléatoire, notamment le fond de carte, ce qui va me faire gagner un temps considérable. Reste à trouver la bonne taille. Je retiens en tout cas ce conseil : sur chaque écran, il doit y avoir quelque chose d'intéressant.

Sinon, deux billets évoquant une erreur courante lors de la réalisation d'un RPG : vouloir faire trop grand

Merci pour les références, je vais les lire avec attention vu que ça me concerne assez directement ;)

Oui et non.

D'une part parce que comme ça a déjà été souligné à plusieurs reprises, il y a une réduction des choix qui est en train de s'opérer de manière globale dans le monde libre (Linux, BSD) autour de quelques solutions, là où auparavant chacun avait sa solution soit-disant générique mais surtout maison. Ce qui fait qu'un développeur pourra bientôt fournir lui-même deux ou trois fichiers d'init pour les quelques solutions majeures, évitant une partie de ce travail à la distribution. D'autant que Gentoo a visiblement fait le même choix dont l'effort pourra être réparti.

D'autre part parce que c'est une nécessité. Systemd ne fonctionnera jamais sur autre chose que Linux, c'est un fait. Donc, il faut bien trouver une solution à l'échelle de Debian et avoir openrc pour tout le monde, qui pourtant semble être une bonne solution, isolerait Debian durablement des autres distributions. Le choix ne devrait se faire que sur cette base. Debian ne pratique pas le sondage pour décider si un paquet reste ou pas dans l'archive (heureusement !). Donc s'ils font le choix systemd+openrc, ils maintiendront ces deux solutions pour un très long moment.

Là par exemple, quoi que le ctte puisse décider, si quelqu'un maintient un paquet pour un système d'init supplémentaire et qu'il fonctionne, il ne se fera pas virer de Debian.

Je ne suis pas tout à fait d'accord. Le ou les systèmes d'init qui seront marqués comme officiels auront un impact sur tous les DD, en particulier devoir offrir systématiquement un fichier d'init au bon format quand il n'en existe pas. Pour un système d'init supplémentaire, ça ne sera pas le cas et ça relèvera de la bonne volonté des développeurs. C'est une grosse différence tout de même.

On peut le voir à l'heure actuelle avec systemd qui est dans les dépôts Debian, mais pour lequel tous les packages qui en ont besoin n'ont pas de fichier d'init au format systemd.

Donc, pour moi, la décision du ctte est plutôt engageante.

Ce qui est le plus déprimant, c'est un journal technique où tu as passé du temps et où il n'y a aucun commentaire

Choisir systemd+openrc me paraît être le choix le plus raisonnable : systemd est partout ailleurs (malheureusement), Gentoo ferait pareil, les variantes non-Linux pourrait avoir un init un peu plus moderne que l'actuel. Mais je crains que les intérêts personnels des membres du comité technique ne viennent jouer les trouble-fêtes.

D'ailleurs, j'ai toujours été étonné par cette instance bizarre au sein de Debian dont personne ne parle jamais mais qui a le réel pouvoir au sein de Debian et qui est tout sauf un truc démocratique. Ses membres sont cooptés, immuables, et en l'occurrence, pas vraiment impartiaux, notamment par rapport à Ubuntu. Bref, on parle souvent du DPL, mais le ctte, c'est le vrai cœur de Debian, c'est là que sont prises les vraies décisions.

Tout le monde s'accorde depuis pas mal de temps sur ce qu'on appelle licence MIT… Ceci dit, elle n'a pas 5 paragraphes, seulement 3.

Comment ça se compare avec Retroshare ?

edit: grillé…