A vous lire j’en conclut une chose : On bosse pareil, grosso modo, meme difference entre grosse boite et petite boites, meme type de chef (ou type d’absence de chef ), la seul vrais difference : c’est que, dans le jeux, dans 70% des taches la ligne “faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code” est inclue automatiquement, donc je resume :
Il faut que ca soit fait (et faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code) pour la semaine derniere (et faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code) sur toutes les plateformes (et faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code) et faut surtout pas que ca bug (et faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code) par ce que la on a plus le temps de debugger (et faut que ca aille super vite et que ca fasse gagner 4Ko de memoire par ligne de code).
hihihi oui. La contrainte d’occupation mémoire n’est pas vraiment un problème sous Windows ou autre OS 32 bits (jusque dans une certaine mesure). Ce genre de contraintes, on les a en embarqué, comme en jeu vidéo je suppose… enfin, même si c’est moins marqué aujourd’hui en embarqué “basique”, je trouve.
J’ai entendu qu’une seule fois un truc du type : “la mémoire, on s’en fout on en a plein”. GRAVE erreur ! ça a “débordé” (OS HP-Unix). Hihihihi, si tu dis ça à un codeur basique, il va te déclarer des tableaux gigantesques… tssss… tssss… tsss…
EDIT : j’ai toujours trouvé que le soucis de l’occupation mémoire (typiquement), était bénéfique à la réflexion en terme de structuration du code .
Ce message a été édité par Moktar le 14/08/2003
J’avais troller comme un porc sur l’autre thread
Ps: pour Shenmu, le projet avais commencé pour la saturn mais n’avais jamais aboutie (je me trompe peut-etre) car le hardware de la console ne lui (le dev que j’ai oublié le nom) permettais pas de faire ce qu’il voulait.
Ce message a été édité par spook le 14/08/2003
Bref, on est tous d’accord qu’en théorie il faut suivre le planning et pas se mettre à improviser par dessus.
Cela dit, parfois dans le jeux vidéo, y’a pas le choix… parce que comme l’a signalé c0unt0, on accumule les problèmes : il faut que ça aille le plus vite possible, que ça prenne le moins de mémoire possible, que ça marche le mieux possible et que ça ne plante jamais Je vous laisse imaginer à quel point certaines de ces exigences sont opposées