Multiportage sur console. comment qu'y font ?

Dev
1

hello les gens !
j’avais créer un thread pour m’informer sur la possibilité de porter du code d’une machine à une autre, même si les architectures sont différentes (PC, ps2 et par extension GC ) mais il a été locké par prévention je suppose…
mais comme j’veut pas mourir con j’en réouvre un !

la réponse au premier thread m’a fait me poser qques questions.
sachant qu’une application peut etre portée comme ca d’un coup de baguette magique d’une console à une autre, je me susi naturellement demandé comment les développeurs se dépatouillaient pour faire le même jeu sur différentes consoles.

parfois il y a des équipes de développent distinctes, du coup on sais que le jeu est censé être optimisé pour la console. mais si je ne m’abuse, il arrive qu’une même équipe fasse toutes les versions ?
nan ?

bref !
parfois, les jeux multiportés laissent un gout amère dans la bouche de certains possesseurs de consoles.
ouais ! a cause de cette saleté de bip mon jeu il est tout pas bien, c’est pauvre en texture, c’est lent, c’est pauvre en polygone, c’est pas bump mappé, etc…

  • du coup je me demande: les multiportages sont ils, comme la légende urbaine le prétends, de simples versions *bip* portés de facon bête et méchante facon je porte connement du code de la *bip* à la *bop* (?)
  • un moteur sur une plateforme est il facilement tranposable sur une autre ?
  • a moins que ce soit simplement la flemme des codeurs ? ou une phase d'apprentissage de certains studio ?
si des codeurs pouvaient me répondre... apres une bonne nuit de sommeil histoire de pas péter les plombs ! hein c0unt0 [img]style_emoticons/<#EMO_DIR#>/wink.gif[/img]

thanks !

2

Bon, personne a répondu encore, je me lance donc

Concernant les équipes, le plus souvent c’est la même équipe qui fait toutes les plateformes, avec certaines personnes spécialisées par plateforme au sein de l’équipe. Cela dit, il arrive parfois que l’éditeur, que ce soit pour des raisons de coûts ou de délais, fasse faire le travail par plusieurs développeurs différents. Voire, parfois, c’est le développeur lui-même qui sous traite les plateformes qu’il ne connait pas (ou pas assez) ou qu’il n’aime pas. Bref, en ce domaine, aucune régle.

Concernant la qualité des jeux sur plusieurs plateformes… tout dépends des moyens mis à disposition lors du développement. Si l’éditeur cherche à tirer les coûts vers le bas au maximum, alors le portage sera une “simple” adaptation de la version originale (quelle que soit la plateforme d’origine). C’est ce qui fait qu’on se retrouve avec des jeux qui subissent des limitations croisées de toutes les plateformes…

Cela dit, certains éditeurs, au contraire, mettent les moyens pour que chaque version soit à la auteur. A ce moment la, chaque version peut être optimisée aux petits oignons par plateforme. Mais c’est relativement rare.

Les moteurs de jeux, en régle générale, font beaucoup appel au hardware et/où au software spécialisé de chaque machine, ce qui les rends assez complexe à porter d’une machine sur une autre. En plus, comme chaque machine a un “data flow” assez spécifique, ça rends la chose encore un peu plus compliquée… Par exemple, sur XBox, la console a une mémoire unifiée : tout est dedans. Sur GameCube et PS2, ce n’est pas le cas, on trouve plusieurs types de mémoires. Il faut donc trouver un moyen de concilier ces deux approches…

Et pour finir sur la flemme des codeurs : non mais oh eh ça va bien de nous insulter la ? Non on est pas flemmards, juste on ne nous donne que trop rarement les moyens nécessaire pour faire tout ce qui devrait l’être… donc il faut faire des choix au final pour sortir en temps et en heure (et dans le budget aussi, ce qui est tout aussi important).

Voila voila, j’ai étalé ma science :o
tuo

3

[quote]Et pour finir sur la flemme des codeurs : non mais oh eh ça va bien de nous insulter la ? Non on est pas flemmards, juste on ne nous donne que trop rarement les moyens nécessaire pour faire tout ce qui devrait l’être… donc il faut faire des choix au final pour sortir en temps et en heure (et dans le budget aussi, ce qui est tout aussi important).[/quote]Puis on est feignants aussi …

4
tuo a dit plein de trucs super interessants !

trop merci, je vais m’endormir moins con c’est clair !
cette phrase m’a également enlevé ques a priori:
blah blah qu’on se retrouve avec des jeux qui subissent des limitations croisées de toutes les plateformes…

toutes les plateformes…
les torts sont donc partagés entre la thune octroyée par l’éditeur, le temps imparti aux développeurs, et le fait que les plateformes ne soient pas unifiés… plus compliqué que ca en a l’air.

merci bien pour avoir pris le temps de me répondre sur ce long post !

5

Ah oui mais la non GloP, si tu dévoile nos secrets professionnels, OU VA LE MONDE, nan mais je te le demande moi hein ! Edites ton post et vite avant que tout le monde le voie
]
Ce message a été édité par tuo le 06/08/2003

6

Je sais passe qu’il a Glop en ce moment, mais il est tout excite : deja hier il s’amusait a faire de la propagande pour sa petite entreprise dans un thread LOCKE, maintenant il devoile nos plus grands secrets professionel…
Il va bientot annonce au monde entier, que non content d’etre feignant, les plus feignant d’entre nous sont souvent les mieux payes (et je peux le prouve ), et la facons la plus rapide d’ecrire du code c’est “Ctrl-V ctrl-$£%”&^%$
ha merde trops tards, ca m’a echape,

desole les gars…

7

Bon c0unt0 tu peux rejoindre GloP au pilori, le temps qu’on décide de ton chatiment.

8

Juste un petit ajout pour compléter les réponses précédentes concernant le portage multiplateforme. On peut également distingués le cas des jeux développés avec des solutions middleware multiplateformes. Parmi celles-ci on trouve des moteurs de physique (Havok, Karma), d’I.A. (DirectIA), de son (fmod, miles sound system), et bien sûr, graphiques (4X, Renderware Graphics). Il existe même des packages de middleware comme le Renderware Palteform qui intègrent l’ensemble. Un trés bon exemple de jeu développé avec ce genre d’outils est GTA3, qui a été développé avec Renderware. L’avantage de ce genre de solutions, c’est que le code le plus difficile à porter, celui qui est le plus pointu, le plus proche du matériel, est déjà porté. Il est ainsi particulièrement facile de “porter” un jeu d’une plateforme à une autre. Attention, j’ai bien dit “porter” pas “adapter”. Bien évidemment, il faut veiller à ce que le code soit portable, c’est à dir, qu’il n’utilise pas de spécificité d’un compilateur particulier. Le plus simple (mais pas le plus efficace en terme de performance) étant de travailler sur un compilateur… multiplateforme (Codewarrior par exemple). Bien entendu, cette solution ne prend pas en compte les limitations inhérentes au hardware de chaque machine (comme par exemple, la quantité et le type de mémoire) qui induisent des compromis au niveau artistique. Dans ce cas, les développeurs et artistes se basent sur une machine fictives qui cumulent les lacunes de chaque machine pour laquelle le jeu est destiné (limitations croisées don tuo parle plus haut). C’est pour cela, par exemple, que GTA3 sur PC souffre des mêmes limitations que sur PS2 (véhicules qui disparaissent dés qu’ils sortent du champ de vision). C’est pour cela que même en utilisant une solution middleware, un bon portage n’est pas qu’une simple histoire de code.
Voilà, voilà, ma petite contribution à ce thread.

9

Juste une petite réaction pour faire mon emmerdeur :

CodeWarrior est un compilateur cross plateforme en effet, mais ça ne veut pas dire qu’il soit moins bon sur chacune de ces plateformes qu’un compilateur “dédiée”. D’ailleurs CodeWarrior est le compilateur officiel Gamecube.

Donc en fait, pour écrire du code portable, il “suffit” d’écrire du code C ou C++ “standard”, sans utiliser les spécificités de la plateforme. Cela dit, dans la vraie vie qu’elle existe vraiment, personne fait ça, y’a TOUJOURS un peu de code spécifique à la plateforme à faire (pour optimiser un brin ou tout simplement pour que ça tourne  )

Voili voila.

10

[quote]Juste une petite réaction pour faire mon emmerdeur :

CodeWarrior est un compilateur cross plateforme en effet, mais ça ne veut pas dire qu’il soit moins bon sur chacune de ces plateformes qu’un compilateur “dédiée”. D’ailleurs CodeWarrior est le compilateur officiel Gamecube.

Donc en fait, pour écrire du code portable, il “suffit” d’écrire du code C ou C++ “standard”, sans utiliser les spécificités de la plateforme. Cela dit, dans la vraie vie qu’elle existe vraiment, personne fait ça, y’a TOUJOURS un peu de code spécifique à la plateforme à faire (pour optimiser un brin ou tout simplement pour que ça tourne  .

11

Je vais faire mon maniaque, mais CodeWarrior est un compilo idiot (tiens je ne suis pas sense dire ca, en fait ) : sur la plus part des plateformes : le code genere est habituellement plus gros et moins efficace, son seul avantage (a part pour le  pc :visual studio inside) : c’est que c’est aussi la seul IDE “integre” (par integre je veux dire : editeur/compiler/linker/debugger) dispo sur 90% des plateformes du marche (en jetant un coup d’oeil sur leur site : mac os X/os 9, pc win/linux, alpha, mips for embended, ps2, gamecube, symbian os 5 -> 8 (psion, p800 et compagnie) et tout un tas d’autres truc !!)
Et que avec CW, meme en utilisant du c/c++ standard, y  a des differences “”“marantes”"" entre les differentes plateformes (et je ne dis pas ca parce que j’ai plus de 7 compilos, pour plus de 6 plateformes differentes sur ma machine de taf (comprenne qui peuve )

12

CodeWarrior n’est pas forcément le compilateur le plus efficace au monde (c’est le moins qu’on puisse dire…) mais au moins, il intégre pleins de choses comme le fait remarquer c0unt0. Et il est dispo sur pleins de plateformes…

Mais il faut savoir une chose : chaque plateforme a son PROPRE compilateur, avec son propre preprocesseur, etc etc. Du coup, tu as des bugs specifique à la plateforme sur laquelle tu compiles La joie quoi :stuck_out_tongue:

Sebastien : je suis d’accord avec toi, un bon codeur devrait, idéalement, adapter son code à toutes les plateformes. Mais voila, on n’est pas dans un monde idéal, et ce n’est clairement pas possible d’adapter son code à chaque plateforme. Et pour 80% du code, ça ne servirait de toute façon pas à grand chose…

c0unt0 : j’avoue qu’en ce moment je n’ai que 3 plateformes cible, mais bon arrete de te plaindre un peu hein :stuck_out_tongue:

13

Mes couilles oui !
hein ? mais de quoi il parle Moktar ?  "Un bon codeur est celui qui optimize son code en fonction de la plate-forme …/…"
PAS DU TOUT D’ACCORD. Un bon codeur est celui qui fait le boulot demandé dans le délai imparti avec du code structuré… pas le monsieur plus qui va passer bêtement du temps à chiader un truc qui n’a AUCUN intérêt. Le codeur dans une équipe de 40 personnes n’a pas forcément (souvent ?) la visibilité sur l’ensemble du projet. Si cette charge n’est pas prévue, il ne faut pas la faire “en perruque”. Si ça a échappé au chef de projet, il faut en discuter … etc. Si le codeur a fini le boulot demandé dans un délai inférieur à celui estimé au départ du projet, il faut qu’il enchaîne sur une autre tâche planifiée et pas “consommer” le temps qui avait été estimé. Les charges restent des ESTIMATIONS, quelques fois elles sont sur-estimées et d’autres d’autres fois elles sont sous-estimées. L’ensemble a de grande chance de se trouver à l’équilibre seulement si le codeur a pas le comportement sus-mentionné et non pas celui du monsieur plus.

Mon avis et mon XP.

14

Moktar, laisse donc tes attributs la ou ils sont

Je pense que les deux definition sont bonnes : tout le probleme, c’est de savoir de quoi tu as besoin a quel moment : si tu fait du tools, de la gestion, ou du bas niveau, ca va change toute ton approche…

Et une definition de “bon programmeur” en gestion ne sera sans doute pas la meme pour un bon programmeur de jeu !

Le seul truc sur lequel je suis tout a fait d’accords avec toi, par contre, c’est pour le respect et la bonne evaluation des delais et des difficulte/risk d’une tache !

Sur ce,je m’en vait faire joujou avec mes compilos

15

Je suis d’accord que l’objectif #1 d’un codeur doit être de tenir les objectifs en terme de temps de développement et en terme de qualité du résultat.

Ceci dit, idéalement, dans un monde parfait, si tout était pour le mieux (je prends assez de précautions pour que vous remarquiez que, de fait, ce n’est pas le cas dans notre monde ?), un codeur devrait pouvoir optimiser son code par plateforme. Mais c’est pas le cas (j’insiste hein, histoire de pas me faire flammer).

(et je parle d’un codeur de jeux video, je connais pas les autres versions du codeur, et ça m’interesse même pas  )

16

De mon point de vue, il n’y a pas de différence de comportement entre un développement pour l’embarqué, le jeu (qui est un embarqué aussi, en fait), la gestion, des outils, etc. J’insiste sur le fait qu’il ne suffit pas de respecter les délais sur une tâche pour que tout roule. Je pense que je ne me suis pas bien fait comprendre.

Si une tâche a été estimée à 3 ho/sem et que tu la cognes en 2 semaines l’erreur “basique” ou plutôt la tendance est de passer du temps à fignoler son code voire ajouter des fonctionnalités pour arriver à 3 semaines et hop tu enchaînes sur l’autre tâche… le problème c’est que si la tâche suivante a aussi été estimée à 3 ho/sem et qu’il en faut finalement plutôt 4, vlan ! tu prends une semaine de dérive alors que si tu avais enchaîné celle-ci à la fin de la première, le défaut d’estimation aurait été absorbé… ok, ok, 1 sem de dérive c’est très faible mais ça peut avoir des conséquences ENORMES sur l’ensemble du projet si on réitère ce phénomène. Sur des petits projets, en général ça ne se sent pas mais sur des trucs de 10 ho/an voire plus, la dérive peut se chiffrer en mois. 

En clair, ma réflexion porte sur l’idée que l’on peut consommer la charge de développement qui a été estimée, pour faire… de l’optimisation ou autre dév… ça, SAIMAL.

17

[quote]En clair, ma réflexion porte sur l’idée que […] consommer la charge de développement qui a été estimée, pour faire… de l’optimisation ou autre dév… ça, SAIMAL.[/quote]Je serais plutôt d’accord avec toi. Pour faire de l’optimisation, il faut l’avoir prévu dans le planning auparavant (donc faut faire la baston avec le chef de projet avant pour qu’il soit écrit sur le planning), sinon, ça part en couille.
 
Le planning part du principe que l’on estime globalement les tâches. Certes seront donc plus longues, d’autres plus courtes que prévues, un bon planning équilibrant les durées, au final. Donc si on utilise le temps gagné sur une tâche sur-estimée pour faire autre chose que ce qui est prévu, on perd l’essence-même du planning pour se retrouver avec finalement un délai minimal (ben ouais, car à partir de là, la seule chose possible, c’est de rallonger les délais). On perd carrément une dimension dans la flexibilité temporelle.

Enfin, ce que je dis, c’est de la théorie d’un jeunot qui sort d’école confirmée par ses petites XP en stages et autres, vu que je n’ai pas l’XP du vieux baroudeur encore
Ce message a été édité par xentyr le 14/08/2003

18

Bah c’est normal si tu fais des estimations a la semaine. Faut decouper son estimation pour que les plus gros machins fassent 3/4 jours pas plus. Faut pas faire ca a niveau managment de haut niveau, mais avec ton chef direct c’est ce qu’il faut faire, sinon tu racontes forcement nawak. Et puis c’est a ton chef direct de savoir ce que tu fais au jour le jour aussi, pas qu’il soit tout le temps sur ton dos, mais etre au courant quoi. Et il faut avoir classe les fonctionalites/changement par ordre de priorite et que tout le monde soit d’accord avant de commencer, comme ca quand il s’agit de couper et de pas faire des trucs parcequ’on a pas le temps, ben on sait par ou commencer sans debat de 397097 ans. (Ha oui et le classement se fait base sur les “user scenarios“ les plus importants… pas sur quelle feature est la “plus cool“ a coder ou a voir…)

Ce message a été édité par GloP le 14/08/2003

19

La meilleure estimation c’est quand même “ça doit être prêt pour avant-hier”…ça a l’air que vous avez de la chance, vous bossez dans des entreprises sérieuses et tout ça.

Mon XP porte plus sur les PME ( voire certaine grosses mais pas dans le domaine de l’info, donc l’équipe info etait petite quand même ), et là c’est le bordel complet, le chef ne fout rien, presque aucune analyse, les estimations c’est à la louche et le plus souvent c’est “ça doit être fait pour demain”. Bref du nawak au niveau de l’organisation, avec des patrons qui s’en foutent completement et c’est toi qui te demerde pour que le programme marche ( avec analyse bien sûr, même si c’est pas ton domaine ).

Je sais pas si c’est le pays ( Espagne ), mais je dirais qu’ici un bon gros 75% des PME/departements infos marchent comme ça ( je base ces chiffres sur le fait qu’aucune de mes connaissances qui bossent ici en info le font dans une entreprise “ou on fait bien les choses” ).

'Tain bosser bien & proprement, ça donne envie…

P.S: je suis sûrement une grosse tache en prog’ en comparaison avec vous…donc je bosse peut-être sur des projets moins importants que vous, ceci explique celà maybe…( mais sur un projet de gestion de chaines hotelieres avec un dev’ qui dure 2 ans, ça devrait avoir un minimum de sérieux à mon avis )

P.S 2 : désolé si c’est hors-sujet, mais je devais le dire

20

Bien d’accord avec toutes ces expériences, fussent-elles pseudo-théoriques .
ZeKiller, je crois qu’on connait tous des projets tels que tu les décrits. N’est-ce pas la majorité d’entres-eux, d’ailleurs ? . Personnellement, c’est le cas et pourtant j’ai parcouru plusieurs domaines d’activités : avionique, aérospatiale, R&D télécom, infra-télécom, “multi-médias”, … ahemmm… militaire (génial d’ailleurs), civile, etc … ce n’est pas fondamentalement lié à l’activité :/.

“aller à l’idéal et comprendre le réel” - J. Jaurès