Voila en réponse a un de mes posts ce que ma répondu El slapper j'ai trouver sa réponse tellement bonne que je me suis permis de la mettre ici .
Mon métier est l'informatique et le bug est mon pain quotidien. "Pain", en rosbeef, ça veut dire douleur!!!
Et faire du sans bug est bien plus dur qu'il n'y parait, tout simplement parceque :
1) il est très difficille de prévoir tous les cas à la conception, et les spécifications doivent souvent être modifiées au fur et à mesure que l'on voit apparaitre des choses.
2) il est impossible de mettre l'ensemble d'un code dans son crâne. Le temps de coder la procédure B, et on a oublié ce qu'il y avait dans la procédure A. D'ou les innombrables problèmes de regression : on corrige B et A se met à déconner parcequ'il dépend de paramètres communs.
3) il est excessivement difficile de tout tester. En effet, les testeurs ont tendance à se concentrer sur ce qui leur saute aux yeux. Donc, quand ils ontéliminé quelques couches de bugs, la suite devient moins visible. En outre, certains bugs bloquants font perdre du temps à tout le monde, en empêchant de tester d'autres parties.
En outre, le jeu vidéo est un domaine ou les programmes sont extrêmement complexes, et réalisés avec des moyens dérisoires en comparaison. Moi dans la banque, j'ai une semaine pour faire ce que Johan(principal programmeur de Paradox) peut faire en une heure. Seulement, ça me laisse le temps de peser les impacts techniques, les temps de calcul, de faire des specs complètes détaillées, de tester en profondeur sur différents environnements, bref, de ne laisser passer des bugs que rarement - et quand il y en a quand même, de réparer les dégâts(une carte Visa avec un plafond trop bas qui ne permet pas de payer le retour d'Andalousie alors même que le compte est alimenté, c'est toujours corrigé très vite).
En bref, le bug est inséparable du programme. En premier, jet, on doit facilement en faire un par ligne de code, si ce n'est plus. Et du temps ou j'étais en maintenance sur les cartes Visa, j'avais 150,000 lignes de code à maintenir. En jeu vidéo, il n'y a même pas de maintenance, que de l'évolution patch avant gel définitif. Et le nombre de lignes doit être infiniment supérieur. Donc, râler quand le jeu n'est même pas jouable, d'accord. Mais quand, de loin en loin, il y a un petit pet de travers, eh ben c'est toute l'histoire de l'informatique.
EL SLAPPER
La spéculation sur la vérité est, en un sens difficile et , en un autre sens facile.
Ce qui le prouve, c'est que nul ne peut atteindre adéquatement la vérité ni la manquer tout à fait .
Il a raison....
Il ya meme des etudes qualités qui indiquent que les tests effectués entre 6 mois et deux ans reviendrait a corriger 1% des bugs. Et puis une banque gere ton pognon, et toi en tant que client tu preferres que ton pognon soit sécurisé (qu'on te le perde pas par exemple du a un bug), tandis que pour un bug rare dans un jeu, tu t'en fous un peu....
OK mais des fois y a quand même du foutage de gueule.
Par exemple certains bugs que tu détectes au bout de trois heures de jeu et qui bloquent le truc dont on se sert le plus souvent dans le jeu. Là tu te dis c'est pas possible les mecs qui ont fait ça ils n'ont jamais joué avec leur produit.
Je ne me souviens plus quels étaient les bugs de Conquests mais je me souviens que j'en avais trouvé un bon nombre dès la première journée de jeu. Et là franchement tu peux pas t'empêcher de penser que les mecs n'ont même pas eu la décence d'engager un testeur pour une malheureuse demi-journée juste pour faire des économies, et qu'ils en ont rien à faire de leurs clients, et qu'à cause de ça il va falloir attendre 3 mois pour avoir leur salopperie de patch, et encore trois mois pour le patch correctif du patch ....
Y a eu l'histoire du patch 1.15 aussi : flagrant, tu allumes le jeu, à l'écran principal tu vois tout écrit au mauvais endroit avec un truc "unité royale machin bidule" écrit à la place de "commencer une partie".
Ben que penser à part que les gars n'ont même pas été foutus d'allumer le jeu juste 5 minutes pour vérifier si ça marchait, et que ce sont des guignols ?
Under the ruins of a walled city
Crumbling towers in beams of yellow light
No flags of truce, no cries of pity
The siege guns had been pounding all through the night.
Bon y en a marre des untités pédestres à deux déplacements Ca fait plusieurs fois que cela m'arrive. Les impi ou les aztecs ou les celtes ont la capacité de se déplacer de deux cases. Mais souvent il arrive qu'après une attaque, il ne reste qu'un impi par exemple et la ville est vide. certains disent que c'est un bug, mais j'ai des doutes : si ces unités ont deux déplacements, peut ête aussi qu'elle sont pénalisées, pour la prise d'une ville. J'entends par là il ne me parait pas anormal du tout qu'un impi qui vient de combattre, ne puisse plus se déplacer par la suite !!! on le voit sur toutes les autres unités, notament les cavaliers, qu'un combat en cours de route, impute sa capacité de déplacement d'une case ! Donc l'impi bas le dernier guerrier mais ne peut plus avancé c est parfaitement normal. La règle qui consiste à donner la ville le tour d'après me parait complétement injuste ! voilà marre de cette règle !
C pte un bug, mais alors faudra m'expliquer pourkoi, il surveint qu'avec les unités terrestres à 2 déplacements ? et uniquement avec cette sorte d'unités ? Je ne suis pas sur, c'est clair mais ca me parait bizarre et j'aimerais bien qu'un super informaticien m'explique en koi c est un bug.
Est ce pssible que l'impi reste bloqué car la prise d'une ville correspondrait par exemple à une capture de trvailleur?
Inao Le 29/01/2005 à 10:45 Il y a effectivement un bug dans civilization qui fait qu'une unité à deux points de mouvement peux capturer un travailleur, puis attaquer une unité, mais ne peut pas attaquer une unité puis capturer un travailleur. Je ne sais pas si cela est lié au bug empéchant la capture d'une ville vide. Il faudrait en outre vérifier qu'il est bien possible de capturer une ville vide avec une unité sans la capacité blitz ayant déjà attaqué dans son tour.
Bon, une infanterie à une case de la case de la ville, qui attaque et détruit le dernier défenseur, prend la ville vide dans le même mouvement que son attaque.

Le cerveau des femmes s'appelle la cervelle.
En principe toute unité qui détruit la dernière unité d'une case doit avancer sur cette case.
C'est vrai quelle que soit la nature de la case attaquée. Ca peut etre une montagne une prairie ou une ville, ça ne change rien.
Le nombre de point de mouvement est en principe indifférent, et il suffit d'avoir 1/3 de point de mouvement restant pour attaquer par exemple une case de jungle (qui consomme 3 points de mouvement) et avancer sur cette case si on tue la dernière unité qui s'y trouvait.
Donc oui il y a un bug dans C3C. Et ce bug est à mon avis lié au combat de pile. Le programme semble ne pas se rendre compte que la ville est vide et laisse les unités attaquantes victorieuses dehors, comme si il restait une unité invisible dans la ville. Ca se produit le plus souvent quand le défenseur tente (ou réussi) de faire entrer des unités dans la ville pendant le combat.
Il me semble qu'il suffit de jouer la dernière unité de la pile d'attaque manuellement (sans utiliser le combat de pile) pour éviter les bugs.
Under the ruins of a walled city
Crumbling towers in beams of yellow light
No flags of truce, no cries of pity
The siege guns had been pounding all through the night.
Arf, on va demander à nos experts en save, peut-être qu'ils nous sauveront.
chris.