zaibatsu a écrit :
Ce qui prête à pleurer c'est leur com... Tout le monde attendait ce patch comme la rédemption d'un jeu qui a survendu ses features depuis sa première annonce. Refonte du spawn, du craft, de l'IA, des fringues, du pathfinding, du loot, de l'économie, du custom de caisse et de perso, enviros destructibles, métro fonctionnel, vue à la troisième personne... la liste est aussi longue que celle de leur hotfixes.

La com est nulle c'est sûr, par contre ce que "tout le monde attendait" faut peut être pas trop s'en soucier. Dans la liste j'ai plus l'impression d'un fantasmes vs réalité qu'un promesses vs réalité. CD Projekt a fait monté la hype de façon démesurée, c'est le retour de bâton donc je vais pas trop les plaindre non plus mais les attentes de certains joueurs me semblent assez incohérentes.
Affirmer que ce qui ne va pas c'est le cœur des mécaniques de jeu et réclamer ensuite des trucs complètement cosmétiques comme un métro ou la customisation des véhicules... heu... ok. En quoi ça va fondamentalement améliorer le jeu ?
Le pire c'est les gens qui réclament une vue à la troisième personne, ceux-là faut pas les écouter, faut les abattre. Ils n'ont pas vu le travail qui a été fait sur la vue à la première personne pour renforcer l'immersion ? Les implications sur le gameplay ? Changer la vue c'est refaire le jeu: mise en scène, combats, tout serait impacté.
Une refonte de l'IA là oui, 100 fois oui. Mais c'est surtout des nouvelles quêtes qu'il faut, c'est ça qui va redonner envie aux joueurs de se plonger dans Night City.

Anglemort a écrit :
Affirmer que ce qui ne va pas c'est le cœur des mécaniques de jeu et réclamer ensuite des trucs complètement cosmétiques comme un métro ou la customisation des véhicules... heu... ok. En quoi ça va fondamentalement améliorer le jeu ?

GTA V a un métro et une customisation des véhicules. Est-ce que c'est indispensable, est-ce que ça sert vraiment à quelque chose ? Non, mais on est très contents que ça soit là, et ça renforce le sentiment d'être dans un monde vivant et pas juste dans un décor en carton. Et puis customiser ses véhicules, dans la mesure où on les voit quand même vachement plus que son avatar, ça parait pas délirant non plus. Au moins pouvoir les repeindre, certaines bagnoles qu'on récupère ont des couleurs absolument hideuses.

Le pire c'est les gens qui réclament une vue à la troisième personne, ceux-là faut pas les écouter, faut les abattre.

Je seconde ce point de vue assez radical.

LordKraken a écrit :
[...]
Mais gardons espoir, un jour Git vaincra :)

(en attendant priez pour nous)

Git n'est absolument pas fait pour gérer de gros fichiers et des fichiers "binaires" (je ne parle pas d'executables) avec un coût non négligeable en perfs sur le serveur. Ça complexifie donc la gestion des assets car il faudrait deux systèmes séparés pour gérer d'un côté le source code, de l'autre le versionning des assets. C'est pour ça qu'on trouve rarement du Git dans le JV, ce n'est tout simplement pas adapté, ça peut faire le taf sur de petits projets mais sûrement pas sur un Cyberpunk. Après je ne dis pas que Perforce est bien, personnellement je ne le connais pas, mais ça explique pourquoi on trouve ce type de solution "alternative" dans ce secteur.

'tain il en aura fait couler de l'encre numérique ce jeu.
Moi ce que j'attends, comme bcp finalement, c' est clairement du contenu. Effectivement qu'il me redonne envie de m'y replonger pour y prolonger ou découvrir certains arcs.

Je me fouts complètement des cosmétiques dans un jeu. En tout cas pas au point de customiser ma bagnole. Le métro a la limite, oui, pourquoi pas, excellent moyen de découvrir la ville. Et on sentait bien qu'à la base, il était prévu mais passé à la trappe.

Je fais plutôt partie du public indulgent aussi. Commencé quasi day one sur pc, kkes bugs mais rien d'entachant vraiment, et totalement happé par ce qui m'était raconté.
Un certains goût de liberté, une ville qui grouille de vie par endroits (oui du décorum, mais c'est tout ce que je demandais) des ruelles que l'on découvre encore après 130h de jeu, etc etc.

Mais oui, tellement encore de choses non finies etc, on ne peut qu'être d'accord avec tout ce qui a été dit plus haut. Apres j'avais pas joué à un fps aussi prenant depuis un bon moment. Beau, fluide, énorme. Je pense que chacun y a vu ses envies, ses attentes, ses déceptions.

Un peu la même chose que certains , je ne comprends pas forcément toute cette cosmeto alors qu'il y avait tant à faire, quoi. Surement tenter de contenter la commu en attendant plus gros 'm' enfin bon...

Pour moi ça a été un bon bouquin. Et comme tout bouquelard qu'on termine, franchement on en redemande, on se dit que le dlc est pas loin, qu'on va replonger.... Pis bah 3/4 patches, certes assez nécessaires, mais 'tain, encore tellement loin de ce que bcp attendaient quoi...

LordKraken a écrit :

muldoon a écrit :

Je comprends pas comment ils ont pu faire un patch de 40go mais ca me choque pas quand j'ai tous les mois des patchs comme ça avec COD Warzone.

Oui bon alors y a jamais 40 go de nouveau code et assets, c'est juste que comme l'industrie du AAA est bloquée sur perforce (et j'ajoute "de merde"), et que tout le monde bosse donc sur une seule et unique branche, bah c'est difficile de faire un diff entre les nouveaux trucs et les anciens, et il est donc beaucoup plus simple et moins risqué de faire un patch ou y a... quasiment tout le jeu complet.

Un exemple, tu retouches une asset de 1mo sur une map de COD, bah pour être sûr que tout fonctionne tu balances les 3 gigas de la map dans ton patch.

Mais gardons espoir, un jour Git vaincra :)

(en attendant priez pour nous)

Je ne pense pas que ça soit lié au source-control, tu peux faire de la merge avec GIT aussi, vive les merges et les gens qui font "push --force". De plus le résultat du build et la capacité à générer un diff binary dépends assez peu du source control.

J'imagine que c'est pour éviter des problèmes a l'application des modifications sur des gros fichiers et aussi pour être sûr qu'un fichier modifié par l'utilisateur soit écrasé. Limite c'est voulu, voyez comment on bosse a font!

Une petite pensée pour ceux qui ont encore des quotas de DL!

Semifer a écrit :
Git n'est absolument pas fait pour gérer de gros fichiers et des fichiers "binaires" (je ne parle pas d'executables) avec un coût non négligeable en perfs sur le serveur. Ça complexifie donc la gestion des assets car il faudrait deux systèmes séparés pour gérer d'un côté le source code, de l'autre le versionning des assets. C'est pour ça qu'on trouve rarement du Git dans le JV, ce n'est tout simplement pas adapté, ça peut faire le taf sur de petits projets mais sûrement pas sur un Cyberpunk. Après je ne dis pas que Perforce est bien, personnellement je ne le connais pas, mais ça explique pourquoi on trouve ce type de solution "alternative" dans ce secteur.

Sauf que ce qui était vrai y a 15 ans ne l'est plus aujourd'hui. Il existe des solutions pour gérer des gros fichiers avec git. Ou alors tu peux faire l'inverse, avoir un repo git au dessus de perforce, ca se fait très bien et on a quelques équipes qui bossent comme ca. Non la raison principale pour laquelle l'industrie aujourd'hui est bloquée sur perforce, c'est que l'immense majorité des TD a 40, voir 50 balais et que ces gars ont juste grandis avec perforce et n'ont plus l'énergie de regarder ce qui se fait ailleurs.

@fennec : je ne comprends pas ce que tu veux dire. Oui on peut faire du caca avec git aussi, ca se fait très bien :) Par contre vu que les branches sont quasi gratuites, c'est infiniment plus simple de mettre en place des process modernes pour scaler tes tests et ta build farm en fonction de ta branche et donc de ta version. Et j'en reviens à ma suggestion initiale, si ton patch vit sa vie dans sa branche, tu n'es plus dépendant du bordel et de l'instabilité de ta branche principale. Du coup tu peux paufiner ton patch tranquillement et tu n'as plus besoin de balancer la moitié des assets "juste au cas ou".

Je ne dis pas ca pour basher perforce, ca fonctionne dans l'absolu, mais je suis convaincu que Git est l'avenir. L'industrie du AAA est d'ailleurs bien la seule qui ne l'ait pas encore compris. Pour conclure sur un exemple perso qui vaut ce qu'il vaut, sur les 10 derniéres annés, j'ai bossé 5 ans sur le plus gros jeu mobile (oui Candy Crush, même pas honte :D), puis 2 ans sur le plus gros jeu à venir de chez Ubi (avatar) et bientôt 2 ans sur le plus gros moteur après Unity et Unreal. Et je pose la question : lequel de ces projets utilise git et non perforce, et lequel de ces projets sort une nouvelle version toutes les 2 semaines sans aucun soucis depuis des années ? (hint : c'est le même).

C'est sur que si ton experience de l'utilisation de Perforce c'est Massive, c'est particulier...
Perso tous les projets sur lesquel j'ai bossé étaient sur Perforce et on sortait plusieurs builds par jour et par branches sans problème.

Quand à Git on y jetera surement un oeil à nouveau quand on pourra foutre les +10 millions de fichiers des projets AAA sans que le serveur se fasse sepuku.

Pour utiliser les deux de manières conjointes depuis plusieurs années, je peux dire que Git a tout de même de gros problèmes qui sont totalement inexistants sous Perforce. De mon côté, je blame l'écosystème Git qui est trop bon et donc permet à tout le monde d'apprendre à l'utiliser (sans nécessairement adopter les meilleures pratiques cependant surtout si c'est des petits projets et/ou avec une collaboration limitée, mais même avec les meilleures pratiques beaucoup de choses restent pétées). Du coup, ils pestent quand ils ne peuvent plus utiliser Git en entreprise.

Git pour les projets avec que du code
Perforce pour les projets avec des assets
Mercurial pour les masochistes
SVN pour les nostalgiques <3

LordKraken a écrit :
Oui bon alors y a jamais 40 go de nouveau code et assets, c'est juste que comme l'industrie du AAA est bloquée sur perforce (et j'ajoute "de merde"), et que tout le monde bosse donc sur une seule et unique branche, bah c'est difficile de faire un diff entre les nouveaux trucs et les anciens, et il est donc beaucoup plus simple et moins risqué de faire un patch ou y a... quasiment tout le jeu complet.

Un exemple, tu retouches une asset de 1mo sur une map de COD, bah pour être sûr que tout fonctionne tu balances les 3 gigas de la map dans ton patch.

T'as 15 ans d'xp mais t'as aucune idée de comment est packagé un jeu? Intéressant :)

Peut-être qu'il pense que git va automagiquement générer son patch delta..

channie a écrit :
T'as 15 ans d'xp mais t'as aucune idée de comment est packagé un jeu? Intéressant :)

Ok, donc sur un projet de 500 personnes, tout le monde doit-être impliqué dans ce processus ? Tu réalises qu'on bosse tous en silo sur ces projets et qu'on a rarement l'opportunité de regarder au delà ?

Mais si tu avais lu correctement déjà c'est 10 ans pas 15, dont 5 ans à sortir un jeu mobile toutes les deux semaines, à partir de git et avec des contraintes effectivement différentes des AAA. Ce n'est pas avec les 2 ans passés ensuite sur Avatar ni évidemment les 2 dernières années sur un moteur que j'ai expérimenté beaucoup de sortie de jeu ni bien sûr de patch/DLC. Le mobile on est d'accord c'est infiniment plus simple, puisqu'on rebalance le jeu entier à chaque fois. Mais je ne pense pas être complètement dans le faux quand j'écris plus haut que si les patchs font 40 gigas aujourd'hui, ce n'est pas parce qu'il y a 40 go de nouvelles données, mais parce qu'on y met toutes les assets liées de prêt ou de loin aux assets modifiées pour être sûr de ne rien louper. Bien sûr on compile/cook les donnés avant de les distribuer, mais rien n'empêche d'avoir une structure un peu plus modulaire.

En revanche, ayant l'expérience des deux systèmes, cela me donne quand même un certain recul pour voir leurs forces et faiblesses. Hors hormis la gestion des gros fichiers, je ne peux que constater les limitations de perforce pour créer des workflows intéressants et un CI solide.

@legreg Pas la peine d'être condescendant hein ;)

@red > on sortait plusieurs builds par jour et par branches sans problème.
-> je n'ai pas dit que ce n'était pas possible, mais ca demande des contraintes matérielles qui font que c'est à ma connaissance ultra limité par les admins perforce (à massive c'était "nej", même pour une grosse feature/proto). Une branche en plus = tu doubles la taille sur ton SSD. Donc si tu as de la chance et un gros SSD, tu peux bosser sur 2 branches, ouais la fête ! Sync tes branches, combien de temps, de minute perdues ? Avoir un vrai CI sans pouvoir créer librement des branches ? bon courage :) Résultat tout le monde prie les 4 vents avant de committer pour ne pas casser master, honnêtement je trouve ca fou qu'on puisse être d'accord avec ca aujourd'hui. J'ai eu la chance, enfin faut aimer jenkins et cie quoi, de bosser sur les CI de candy crush, avatar, et un moteur donc. Le premier était "presque" un plaisir, les autres, une galère sans fin. Discutes en avec les ingés qui s'occupent de ta build farm, demandes leur comment ils s'éclatent avec les builds qui cassent tout le temps ;)

Encore une fois, si ta seule expérience avec Perforce c'est celle que tu as (eu?) avez Massive, c'est loin d'être le meilleur exemple d'utilisation de Perforce.
Ca fonctionne mais Perforce n'est pas été conçu pour être utilisé comme ils le font.
Pour les builds qui pètent, le jour où les utilisateurs testeront leurs modifs avant de les soumettre et d'accuser le CI, je perdrais effectivement moins temps...

Ce n'est pas que Massive, c'est aussi mon taf actuel, donc évidemment 2/2 ca fait 100% de mon expérience, et 4 ans à regretter git chaque jour que Odin fait, mais je serais ravi d'en apprendre plus sur ton setup perforce et votre CI (et je dis ca très sérieusement).

LordKraken a écrit :
Mais je ne pense pas être complètement dans le faux quand j'écris plus haut que si les patchs font 40 gigas aujourd'hui, ce n'est pas parce qu'il y a 40 go de nouvelles données, mais parce qu'on y met toutes les assets liées de prêt ou de loin aux assets modifiées pour être sûr de ne rien louper.

Je te laisse réfléchir 2 minutes à tout le data qui peut être généré suite à la modif d'une boite de coll, d'un shader ou d'une ligne de dialogue.

LordKraken a écrit :
Une branche en plus = tu doubles la taille sur ton SSD

Ca fait bientôt 10 ans qu'on ne duplique plus l'entiereté du dépot quand on switche vers un stream avec Perforce :)

LordKraken a écrit :
Discutes en avec les ingés qui s'occupent de ta build farm, demandes leur comment ils s'éclatent avec les builds qui cassent tout le temps ;)

Massive, le studio où t'as besoin d'un DT derrière chaque artiste et designer pour pas que ça pête :D Sérieux vous avez les streams de Perforce + Teamcity qui détecte/build automatiquement les nouveaux streams, vous avez du preflight gratos et vous ne vous en servez pas?

LordKraken a écrit :
Ce n'est pas que Massive, c'est aussi mon taf actuel, donc évidemment 2/2 ca fait 100% de mon expérience, et 4 ans à regretter git chaque jour que Odin fait, mais je serais ravi d'en apprendre plus sur ton setup perforce et votre CI (et je dis ca très sérieusement).

Qu'est ce que tu veux que je te dise. Ca fait 15 ans que je fais ce métier, j'ai ship une dizaine de jeux dont les 3/4 étaient des AAA, quand j'ai commencé il y avait pas de CI. J'ai plein de trucs à reprocher à Perforce mais le problème c'est surtout qu'il y a rien d'autre qui lui arrive à la cheville pour faire un AAA, et c'est pas faute d'avoir cherché. Perforce comme beaucoup de logiciel de ce type, il fait ce qu'on lui demande. Si tu lui demandes de la merde il te fera de la merde...

Pour le CI bah comme beaucoup on utilise Jenkins, Teamcity ou des solutions maison. Le cloud aussi a apporté une grande flexibilité. Et bien sur Perforce en source control.

channie a écrit :
Je te laisse réfléchir 2 minutes à tout le data qui peut être généré suite à la modif d'une boite de coll, d'un shader ou d'une ligne de dialogue.

Prends moi pour un idiot. C'est peut-être AUSSI un problème de design de ton engine ou de ton archi si tu dois shipper 10 gigas de données quand tu corriges une erreur de syntaxe dans une ligne de dialogue, non ?

C'est dommage de prendre les gens de haut, voir même de partir sur des attaques ad-nominem... On dirait vraiment que j'ai commis le sacrilège ultime en n'adoubant pas perforce :) On a tous nos expériences et et les miennes sont clairement différentes des vôtres, mais en attendant ça fait 4 ans que je vois des devs galérer régulièrement et des CI du moyen âge, en partie, je pense, à cause de perforce. Et pas que à Massive.

Franchement vous donnez quand-même l'impression de ne pas avoir touché beaucoup à git pour ne pas lui reconnaître certains avantages sur perforce. (d'ailleurs qui développe un outil intégrant git au dessus de perforce ? ah tiens, perforce lui-même)

Maintenant je ne connais pas Teamcity, donc je vais regarder, histoire de retirer un peu de positif de cette discussion au ton assez détestable (ce je trouve triste honnêtement).

Bah écoute tu as l'air de t'y connaitre plus que moi, du coup j'ai rien à ajouter.

Red1812 a écrit :
Bah écoute tu as l'air de t'y connaitre plus que moi, du coup j'ai rien à ajouter.

Ce n'est absolument pas ce que j'ai écrit, bien au contraire, ou alors je ne sais plus écrire en français correct :) Je fais uniquement part du constat, mon constat, sur une période de 4 ans et dans 2 compagnies différentes, de quelqu'un qui arrive sur perforce avec un background git. S'il existe un workflow perforce de meilleure qualité et qui répond à mes attentes, je ne demande qu'à apprendre, ce qui était d'ailleurs le sens de la question posée au dessus, à laquelle vous avez choisi de répondre avec mépris.

Il n'y avait pas grand chose à commenter, ta première intervention c'était pour dire que au moins avec Git on aurait pas des patches de 40GB, et cela sans vraiment d'explication technique (au delà de "je vois les gens galérer avec Perforce ça doit être pour ça que les patches font 40GB"). On est programmeur aussi et le "handwaving", ça ne va pas très loin.