De l'iPhone vers l'AppUp : Portage de « Ancient Frog »
La suite est une continuation d'une série d'articles sur le portage depuis l'iPhone* vers le centre Intel AppUp(SM). Il s'agit de l'interview que j'ai réalisée avec le développeur James Brown à propos de son expérience dans le portage sur le centre Intel AppUp depuis l'iPhone* de son jeu primé « Ancient Frog ».
Q.Où avez-vous trouvé votre inspiration pour le jeu ?
James Brown :
« Ancient Frog » est né de mon départ de la grande industrie des jeux. Je suis en fait concepteur, programmeur, artiste et producteur. Mais l'industrie des jeux est devenu quelque chose d'énorme, elle s'est stratifiée et j'ai fini chez Lionhead/Microsoft comme manager d'une équipe de programmeurs, en ayant plus aucun réel apport créatif, ce qui était aussi éloigné que possible du job idéal dont je pouvais rêver.
J'ai donc décidé de lancer à nouveau mes propres jeux. J'ai été amené à l'idée d'Ancient Frog par les contraintes que je m'étais fixées. J'avais besoin d'un jeu suffisamment petit pour pouvoir être réalisé aux standards professionnels par un développeur solo. Avec un puzzle, une fois que vous avez identifié la mécanique du puzzle, le reste est juste une variation sur le même thème. Je voulais également un personnage central, mignon mais pas trop, avec un peu de personnalité. Comme je ne suis pas animateur, cela m'a amené à regarder du côté des systèmes d'animation procédurale et l'idée d'un jeu d'escalade impliquant un gecko a commencé à s'ébaucher.
Une fois que j'ai eu dessiné le squelette d'un prototype, l'idée a pris forme et a évolué au fur et à mesure que je jouais avec. Le gecko s'est transformé en grenouille car les pattes des grenouilles sont plus longues à l'arrière qu'à l'avant, ce qui introduit la possibilité d'un certain nombre de décisions intéressantes pour le joueur. Le côté escalade a peu à peu disparu pour faire place à l'idée légèrement plus abstraite de la marche sur des gouttelettes. Le système d'animation est devenu plus explicite : vous ne pilotez pas la grenouille, vous tirez un membre à la fois, ce qui en fait un puzzle plus intéressant et ce qui signifie que c'est le joueur qui crée l'animation, et non le jeu.
La route a été longue depuis ce prototype initial jusqu'au jeu dans sa version finale (pendant ce temps, j'ai changé de pays et passé du temps à élaborer des vidéos interactives numériques pour des musées), mais l'idée de base est restée très claire pendant tout ce temps-là.
Q. La présentation d'Ancient Frog est très particulière. Comment avez-vous aborder la conception de ce jeu, à savoir outils, API ?James Brown :
L'outil principal utilisé dans la création du jeu a été le jeu lui-même. La majeure partie du code écrit pour Ancient Frog l'a été pour les outils et les éditeurs internes (y compris le code de génération des puzzles et de recherche des solutions optimales pour ces puzzles, ce qui était un défi particulièrement intéressant). Le plus important aspect du design a de loin été le fait que j'ai rendu modifiable à la volée tout ce que j'ai pu. Lorsqu'il s'agit de construire une expérience interactive agréable, rien ne remplace l'itération constante. Vous essayez quelque chose, vous le testez, vous le corrigez encore et encore jusqu'à ce que toutes les aspérités et les aspects ennuyants aient disparu. Puis vous continuez à ajouter quelque chose qui va plaire et qui va surprendre. Et là encore, vous rabotez les aspérités et éliminez les aspects ennuyants des nouveautés introduites.
Tout est piloté par les données et, en surveillant les changements sur le disque, le jeu peut recharger les modifications en toute fluidité. Vous peignez une texture dans Photoshop*, vous cliquez sur Enregistrer, et la voici dans le jeu. Il n'y a pas de magie dans le code. J'ai une petite classe « règle » basée sur un modèle qui se comporte comme un type natif, ce qui fait que le seuil de commodité pour tout exposer aux données est extrêmement bas. La souplesse de cette patte ? La durée de ce fondu enchaîné ? L'accélération due à la gravité ? Même si je suis sûr de ne jamais vouloir le changer, c'est là, et si l'envie m'en prend pendant que je teste, je peux juste jouer avec ce que je veux pour voir ce que cela donne. Si vous avez besoin d'arrêter, de recompiler et de revenir où vous en étiez, vous atteignez facilement le point où un changement est plus une source d'ennuis qu'autre chose.
Le look particulier d'Ancient Frog est réellement issu de l'exigence que je me suis imposée pour une indépendance maximum aux résolutions d'écran. Je voulais pouvoir tourner sur n'importe quoi allant de 640x480 à, disons, 1920x1200 sur deux moniteurs, avec n'importe quel rapport d'aspect et avec un format d'image allant du portrait à l'écran large. L'une des choses qui m'ennuyaient dans mon précédent jeu chez Lionhead, c'était que le changement de résolution obligeait à redémarrer le jeu. Maintenant que je fais tout moi-même, je voulais faire les choses proprement ; non seulement j'allais permettre les changements de résolution à la volée, mais j'allais le faire de telle sorte que si vous saisissiez la fenêtre et la redimensionniez ou lui donniez n'importe quelle forme, le contenu s'adapterait de lui-même en toute fluidité. Cela peut sembler une décision techniquement bizarre et peu importante, mais au final ce choix a eu un impact énorme, à la fois en termes de look unique et de possibilité de portage sur un nombre extrêmement diversifié de plates-formes.
Si je m'étais cantonné aux formats d'image les plus logiques, j'aurais pu m'en tirer en créant des graphismes avec un peu de retouches sur les contours et de rognage pour les faire tenir à l'écran, mais le fait qu'à chaque fois que j'exécutais le jeu, je pouvais jouer avec la taille de la fenêtre, signifiait que je voulais voir ce qui arriverait si je l'élargissais. Ou l'agrandissais. Ou la rendais énorme. Ou minuscule. Et lorsque vous vous adonnez à ce petit jeu, vous butez rapidement sur les limites de mise en page fixe. C'est pourquoi j'ai conçu un moteur de mise en page piloté par des fichiers de niveau XML, qui élaboraient des niveaux dans des couches. Chaque couche peut avoir toutes sortes de règles de mise en page, mais la stratégie de base est d'avoir une couche pour tenir la zone de jeu, qui essaie de remplir toute la fenêtre, et une ou plusieurs autres couches d'avant et d'arrière-plan qu'il est possible de disposer en mosaïque, d'étirer ou de rogner pour remplir le reste de l'écran.
Une fois que l'idée m'est venue d'élaborer les niveaux dans des couches, il était naturel d'introduire de la vie et du mouvement sur l'écran, de la profondeur de champ et de la parallaxe. Je me suis servi de photos pour fournir les textures aux couches (feuilles, troncs d'arbre, mousse, pierres, etc.) et l'approche avait beau avoir l'air prometteur, il m'a fallu plusieurs mois pour obtenir un ensemble cohérent. La solution est venue alors que je nettoyais le fossé de drainage en face de chez moi et que mon attention a été attirée par le motif des ombres créées par des arbres sur la porte du garage. C'était une danse en évolution constante, mais avec une simplicité sous-jacente basée sur l'interaction de quelques formes et de quelques rythmes simples. Une fois rentré, j'ai codé une copie de cet effet et l'ai ajouté comme couche par dessus chaque niveau en utilisant un mélange multiplicatif pour donner un look riche et saturé à chaque élément, ce qui a fini par donner son style définitif à l'ensemble du jeu.
Sur combien d'appareils tourne Ancient Frog et avez-vous démarré le développement d'une plate-forme à l'autre ?
James Brown :
Ancient Frog est disponible sur Apple* iPhone* et iPad*, Palm* Pre* et Pixi*, et maintenant les netbooks basés sur les processeur Intel® Atom™. J'ai également un portage Android* (mais pas moyen de le vendre à partir de la Nouvelle-Zélande pour le moment), ainsi que des versions PC et Mac* où je suis toujours hésitant sur les meilleurs vecteurs de ventes.
En fait le prototype initial a été écrit pour mon téléphone (à l'époque, un appareil Windows* Mobile avec un écran de 240x240). La plupart du temps où je jouais à des jeux, c'était à des moments occasionnels comme à l'arrêt de bus ou la queue à la caisse du supermarché, et je voulais créer quelque chose dans cette veine. Mais c'était avant l'irruption de l'iPhone*. L'espace smartphone était très fragmenté et je n'avais pas une idée claire des spécifications que je devais viser ou de comment vendre un jeu à des utilisateurs de smartphone. J'ai donc mis cela de côté et je suis passé au développement sur PC. Mais l'idée de mettre ultérieurement le jeu sur un téléphone ne me quittait pas et, tout au long de mes développements, les exigences de portabilité et d'extensibilité étaient au centre de ma réflexion.
J'ai découvert que moins je dépends de bibliothèques externes, et plus mon code est portable. Il y a certainement de bons arguments en faveur des bibliothèques d'utilitaires, des moteurs ou de l'intergiciel, mais ils ne sont un avantage que s'ils tournent sur la plate-forme qui vous intéresse. Si une de vos dépendances ne marche pas sur la cible qui vous intéresse, vous ne pourrez pas y faire grand chose. J'utilise SDL (Simple DirectMedia Layer) sur le PC, mais c'est une couche très mince et suffisamment facile pour coder des alternatives si vous en avez besoin (comme je l'ai fait pour iPhone* et pour Android*).
Sinon, c'est juste du code C++ ciblant OpenGL*. C++ est un choix sûr (quel que soit le langage bizarre recommandé sur une plate-forme particulière), vous pouvez être tout à fait sûr que le compilateur C++ était là avant (ne serait-ce que pour compiler ce langage). OpenGL* est très largement disponible par défaut (même sur Windows*, ils préféreraient vous voir utiliser Direct3D*, mais ils ne vont pas jusqu'à insister pour cela). Il est également très facile d'utiliser un sous-ensemble bien défini d'OpenGL* et, sur les plates-formes où ce dernier n'est pas disponible, de mettre en œuvre vous-mêmes ce sous-ensemble.
J'effectue la majeure partie de mes développements sur Windows* à l'aide de Visual Studio*, mais j'utilise un Macbook* Pro pour les développements quand je ne suis pas au bureau. C'est excellent pour la portabilité de votre code si vous construisez régulièrement sous deux compilateurs et deux systèmes d’exploitation différents. C'est suffisant pour identifier la majorité des problèmes inter plates-formes avant qu'ils ne s'installent et ne s'incrustent, et c'est pourquoi je n'ai pas eu beaucoup de mauvaises surprises lors du portage sur une autre plate-forme.
Q. Quels outils et quelle méthode avez-vous utilisés pour porter votre application en vue d'une expérience netbook et pourquoi avez-vous pris cette route ?
James Brown :
Le jeu tournait déjà sur Windows* et les résolutions des netbooks étaient couvertes par le travail que j'y avais fait à l'origine, donc « portage » est un bien grand mot pour le travail qui était requis.
Je n'ai pas pu tester sur une palette très étendue de matériels cibles, aussi ai-je construit mon application en utilisant les réglages les plus conservateurs (mon moteur de jeu a quelques réglages que je peux utiliser en fonction des capacités de la cible) et j'ai désactivé les objets framebuffer et le support de prise en charge du nuanceur. Lorsque j'aurai un peu plus de données sur le niveau de support des pilotes, je les réactiverai probablement et je rendrai le jeu un peu plus brillant.
Comment vous y êtes-vous pris pour les différences entre matériels comme l'interaction tactile multipoint par rapport à la souris et au clavier, ou l'accéléromètre dans l'iPhone* ?
James Brown :
En fait, Ancient Frog n'utilise pas vraiment de matériel qui ne puisse être répliqué avec une souris ou un trackpad. J'utilise l'accéléromètre pour influencer la direction de la chute des pétales dans l'animation win, mais cela ne nuit pas au jeu si l'on perd cette fonctionnalité. L'interaction tactile multipoint est utilisée dans la version iPad*, ce qui fait que vous pouvez plonger plus d'un doigt dans l'eau en même temps. Là aussi, ce n'est pas grave si l'on perd cette fonctionnalité.
Dans les versions d'Ancient Frog pour écran tactile, le jeu commence par un tutoriel d'introduction qui retire le contrôle au joueur. On peut admettre que cela peut ennuyer quelques joueurs (mais des tests ont montré qu'il était nécessaire d'enseigner certains gestes de contrôle). Mais pour certaines raisons, sur une machine dotée d'un contrôle indirect (souris ou trackpad), cela devient totalement inacceptable. Je ne suis pas sûr de savoir pourquoi ; peut-être que ne pas réagir à un toucher est quelque chose qui est toujours contextuel, et donc attendu, tandis que ne pas réagir à la souris donne davantage l'impression que la machine est plantée, ce qui n'est pas attendu.
En tout cas, j'ai dû modifier le tutoriel pour en faire davantage un conseil pratique. J'ai également supprimé les fonctions Annuler et Rétablir, en partie parce que les gestes sont maladroits avec une souris ou un trackpad et aussi parce qu'un espace d'affichage plus grand signifie qu'il y de la place pour des boutons à l'écran. Avoir des boutons à l'écran signifie également que le joueur est incité à jouer avec eux pour voir ce qui se passe, ce qui allège le tutoriel.
Q. Est-ce que quelque chose vous surprend sur le processus du portage ? Serait-il par exemple plus complexe ou plus facile que vous ne le pensiez ? Avez-vous perdu ou au contraire enrichi des fonctionnalités pour le netbook ?
James Brown :
L'approche utilisée par Ancient Frog pour créer son look, avec ses multiples passes de mélange, est très intense en taux de remplissage. J'ai eu du mal avec cela dans le portage sur iPad*, que j'ai effectué juste avant la version netbook, car la GPU de l'iPad* ne peut tout simplement pas gérer ce découvert. J'ai dû passer du temps à injecter de l'éclairage dans les textures, à supprimer des éléments de la mise en page et, en général, à tailler dedans pour qu'il puisse fonctionner. Je me faisais donc du souci à l'avance pour la version netbook, où je craignais de rencontrer le même problème. Eh bien, j'ai été agréablement surpris par la vitesse de la puce graphique intégrée et je n'ai rien eu besoin de couper.
Q. Comment comparez-vous le jeu entre les appareils ?
James Brown :
Le jeu est essentiellement le même sur tous les appareils. Sur les terminaux de poche, le look des niveaux est simplifié : ils n'ont qu'une seule couche et ils sont rognés étroitement pour utiliser au maximum ces écrans minuscules. Sur les versions netbook, les grenouilles ont plus de place pour respirer et plus d'éléments d'arrière-plan sur lesquels rebondir. Mais, hormis quelques petits ajustements de la progression en difficulté, les puzzles sont identiques.
Q. Avez-vous eu besoin du support d'Intel pendant le processus ? Comment s'est déroulé le processus de soumission et le support pour le centre Intel AppUp comparés à d'autres boutiques ?
James Brown :
Tout s'est passé très simplement. J'ai eu un échec de validation car je m'étais débrouillé pour construire contre une ancienne version du SDK, mais après cela, tout s'est passé sans problèmes.
Q. Y-a-t-il quelque chose que vous feriez différemment, ou avez-vous peut-être des conseils à donner aux développeurs qui envisagent de porter depuis iPhone* vers le centre Intel AppUp ?
James Brown :
La seule chose que je ferais différemment serait de le faire plus tôt. Construire pour le centre AppUp nécessite si peu d'efforts et je suis réellement excité de voir où cela va.
Le meilleur conseil que je puisse donner pour le portage depuis iPhone* vers le centre Intel AppUp est de construire votre application iPhone* avec le portage à l'esprit depuis le début directement de C++ et d'éviter les API spécifiques à Apple*. Si vous avez déjà fini votre application iPhone* et que vous vous demandez si cela vaut la peine de la restructurer pour la rendre indépendante à l'égard de toute plate-forme, sachez qu'en dehors du fait d'avoir recours à un nouveau portage, il y a des avantages à utiliser le code original. Des appareils différents tendent à exposer des bogues légèrement différents et, comme le code est le même sur toutes les plates-formes, les correctifs que vous apporterez bénéficieront à toutes les versions.
Si vous avez l'intention de construire pour iPhone* et le centre Intel AppUp, il est plus logique de traiter le centre Intel AppUp comme cible principale pendant le développement. Vous voudrez pouvoir itérer rapidement et le débogage d'un netbook est considérablement plus rapide que celui du simulateur iPhone* ou que le téléchargement vers le matériel physique.
