Suite à la première partie de mon article voici la 2e partie, s'axant sur le développement concret sur Wii U blog_article324860.html

Commençons le travail
Les premiers kits de développement commencent à arriver. Comme d'habitude pour le Hardware les kits de devs sont d’énormes caissons avec pleins de connecteurs, contrairement au modèle final constitué d’un mélange de connecteurs et de ports utilisés spécifiquement pour le développement. Nous les avons donc branché et les flashé avec la dernière version du code du système, alors essayé d'obtenir un simple "Hello World " qui s'est avéré plus difficile que vous pourriez penser, juste pour le faire apparaitre.

Ayant travaillé sur d'autres consoles au hardware divers et varié, je suppose que nous étions plutôt gâtés en ayant en notre possession les outils de développement mis à jour et très proche du Hardware qui s’intègrent parfaitement à notre environnement de développement. La Wii U en revanche semblait essayer de nous mettre des bâtons dans les roués et de nous rendre la tâche difficile pour compiler et exécuter n'importe quel code. Nintendo avait prévu une intégration de leurs outils de développement dans Visual Studio le standard de facto pour le développement, mais cela n'a pas vraiment fonctionné et les temps de compilation ne se sont pas raccourcis pour autant.
Donc nous avons passé un temps monstre pour régler ces problèmes et de les signaler à Nintendo qui de leur coté distribuaient ces optimisation aux autres développeurs “privilégiés”. Finalement, nous avons reçu une solution de Nintendo via une autre société tierce qui avait également travaillé sur cette question pendant un certain temps et le développement c’est donc déroulé en optimisant les temps de travail et en échangeant les solutions entre divers développeurs de sociétés différentes.

Maintenant, nous avançons et developpons le code visible dans Visual Studio et obtenons la compilation, ce qui était déjà un bon début, mais les temps de compilation étaient encore vraiment longs et lents, même pour des changements mineurs.
Ensuite, on a dû faire l'étape de liaison, code-machine. Juste pour vous dire, vous avez le temps de vous faire une tasse de thé, avoir une conversation avec un collègue de travail et revenir à votre bureau avant que le tout soit complété. Les temps de compilation de code sont de l’ordre de 4-5 minutes sur WiiU à comparer à d'autres plates-formes.



Cela ne semble pas un drame en soit, mais quand vous vous mettez à déboguer et faire beaucoup de changements, ces temps supplémentaires s'additionnent. Si vous avez fait 10 modifications à un fichier en une matinée, vous pourriez dépenser plus de 50 minutes d'attente pour l'éditeur de links, ce qui est beaucoup de temps perdu et pour l’éditeur et de l’argent bien sûr. Hormis ce temps perdu, ce même temps peut être consacré, dans le peaufinage du jeu, chose qu’en début de développement on n’a pas connu.

"En tant qu'équipe, nous avons perdu des jours aux frais de la compilation / link / débogage et cela a affecté négativement le nombre de fonctions que nous pourrions mettre dans notre jeu avant la date de sortie."


Il s'agit d'un kit de dev Wii U, a révélé au monde de VGLeaks un peu plus petit que les kits ALPHA de console next-gen à base de composants PC. Les Kits dev fusaient, mais des révisions de matériels réels ont toujours été assez minimes.

Enfin, quand vous le code, vous le déployez sur la console et lancez le débogueur, qui faisait partie de l'ensemble des outils de developpement que Nintendo a, donné une licence de distribution à Green Hills Software. En tant que développeur chevronné, j'ai utilisé beaucoup de débogueurs, mais celui-ci m’a surpris moi-même. Son interface est maladroite, le débogueur était très lent à utiliser et si vous faisiez l'erreur de cliquer sur n'importe quel code, il faisait une pause et récupérer toutes les valeurs des variables que vous aviez cliqué, ce qui peut prendre une minute ou plus à revenir en arrière.

Toutes ces choses ont rendu le développement de jeu vraiment difficile et laborieuse, se qui est dommage, la technique et Nintendo ou leur sous-traitance n’était pas exemplaire. En tant qu'équipe de développement nous avons perdu du temps pour la compilation / link / debug et cela a affecté négativement le nombre de fonctions que nous aurions pu mettre dans notre jeu avant la date de sortie.

Autre chose curieuse, à noter à ce point était que, au cours des six mois, nous avons reçu plusieurs kits de développement différents dans une variété de couleurs différentes, dont aucune ne révélais pourquoi ils étaient différents des précédents. Nous savions qu'il y avait quelques bugs matériels qui ont été corrigés dans ces nouvelles colories au fil du temps, mais les logs indiquaient rarement ce qui avait changé nous avons juste eu à prendre les nouvelles et les faire travailler avec notre code à nouveau, en nous faisant encore perdre du temps de développement précieux. Il y a eu quelques rumeurs intéressantes qui circulaient, de boites de développement au design proche de ceux d’un PC, et même qu’une Radeon HD 4850 (en cours d'exécution underclocké) était utilisé comme un proxy pour le GPU de la Wii U. Nous avons travaillé sur Wii U dès les premiers jours et n'a jamais vu l'équipement comme cela nos kits avaient toujours la forme de compilation de Hardware personnalisé au look des années 60.

Travailler avec sur Wii U
Maintenant que le jeu tournait sur la console, nous pouvions désormais développer des caractéristiques qui sont propres a la Wii U comme le Gamepad et les Wiimotes issue de la précédente console de Nintendo, de quoi se démarquer de la concurrence, et apporter une plus value au jeu.
Peu après le début du travail sur ces nouveaux controlleurs, nous avons fait face à des problèmes que la documentation fournie par Nintendo n’était pas en mesure de nous renseigné. On a donc demander à l’équipe locale de Nintendo, apte à aider les développeurs en cas de soucis technique, et ceux-ci, impuissants face à nos questions ont du faire remonter les questions au support technique japonais, sur lequel nous avons attendu, et attendu et attendu.



Après environ une semaine de demandes intenses de notre part de réponse, Nintendo Japon nous ont alors envoyé un email entremêlé de phrase dans un anglais très approximatif, voir en dessous d’un anglais scolaire. Nos questions dans ces mails n’étaient qu’à peine répondues voir pas du tout. Nous leur avons redemander des éclaircissements qui nous ont couté encore 1-2 semaines d’attente.


Après ce deuxième retard de Nintendo, nous avons demandé au support technique local, pour cela prenais autant de temps, leur réponse était on ne peu plus claire, à cause de la barrière de la langue, les questions étaient envoyés en anglais a des traducteurs, qui les traduisirent en japonais qui y répondaient, puis renvoyèrent au support traduction de Nintendo qui nous les renvoyant de retour. Avec les fuseaux horaire et tout se qui s’en suit, le temps de réponse est des plus corrects et cela prend habituellement 1 semaine.

Obtenir un jeu le faisant fonctionner à sa fréquence d'image cible (30-60FPS) est une partie du processus de développement qui est la moins intéressante dans ce contexte, car il suit le modèle standard. Faut obtenir un jeu qui marche, si cela n’est pas le cas faut le couper de certaines features et optimiser le couple GPU CPU pour avoir le meilleur rendu/qualité finale.


La première comparaison fut faite dans les différentes version de Mass Effect 3 ou la version PS3 est la plus décev ante en termes de FPS, la version Xbox 360 et Wii U sont très similaires.

En ce qui concerne les optimisations CPU, oui, nous avons dû réduire certaines caractéristiques en raison du petit CPU faut d'être assez puissant. Comme nous le craignions à l'origine, en essayant de soutenir un jeu de course détaillées en HD cela a mis beaucoup de charge sur le CPU et nous n'avons pas pu faire autant que nous l'aurions souhaité. Couper certaines des caractéristiques était une chose facile à faire, mais cela a une incidence sur le jeu dans son ensemble. Optimisé un code pour des processeurs PowerPC de Xbox 360 et de PlayStation 3 n'a pas toujours été le meilleur moyen pour obtenir quelque chose de potable pour le CPU Wii U, et bien que la puce dispose de quelques fonctionnalités intéressantes qui permettent de tirer parti du CPU, nous ne pouvions pas prendre possession de tout son potentiel. Cependant en optimisant le code nous avons pu faire tourner le CPU à un regime decent et avoir des IPC supérieures (instructions per cycle) par l'inclusion d'exécution out-of-order .

Du côté du GPU, l'histoire s'est inversée. Le GPU s'est avéré très capable et véloce, cela a fini par l'ajout de fonctionnalités supplémentaires et de polisher le tout, comme le GPU avait la capacité de le faire. Il y avait même des discussions pour essayer d'utiliser le GPU via shaders de calcul (GPGPU) pour décharger le travail de la CPU, exactement l'approche que je m'attends à voir qui gagneront du terrain sur les consoles next-gen, mais avec le temps de développement très limité et pas d'exemples ou conseils de Nintendo, nous n'avons pas l'impression que nous pourrions risquer de tenter ce travail.

Si nous avions une équipe de développement plus ou une période plus longue, peut-être que nous aurions essayé de le faire, mais avec le recul, nous aurions été limitée à ce que nous aurions pu faire avant que nous domptions le GPU à nouveau. Le GPU est mieux que sur PS3 ou Xbox 360, mais à mille lieues du matériel graphique dans la PS4 ou Xbox One.

J'ai aussi vu des préoccupations au sujet de l'utilisation de mémoire vive DDR3 sur Wii U, et un déficit de la bande passante par rapport à la PS3 et la Xbox 360. Ce n'était pas vraiment un problème pour nous. Le GPU pourrait récupérer les données rapidement et avec un minimum de stalls (via le EDRAM) et nous avons pu efficacement faire un pré-fetch, ce qui permet au GPU de fonctionner à un vitesse supérieure.

Fin de la deuxième Partie