Le succès du développement d’applis pour iPhone amène de nombreux développeurs à considérer d’autres plates-formes, afin d’étendre leur marché. Pour certains, cela se traduit par le portage de leurs applis vers Intel AppUp, ce qui bien sûr présente à la fois défis et opportunités.
Mike Kasprzak, Directeur Général de Sykhronics, partage ici avec nous son expérience du portage du jeu « Smiles » de l’iPhone vers Intel AppUp.
Mike Kasprzak :
J'ai tout d'abord utilisé OpenGL pour les graphiques. Virtuellement chaque plate-forme qui vaut son pesant d'or dispose de sa propre version d'OpenGL (ou d'une API similaire). C'est d'ailleurs la seule API de graphiques 3D disponible sur Mac, Linux et d'autres plates-formes mobiles. Elle est accessoire sur Windows, mais elle est toujours gratuite. OpenGL est en fait une API bien plus vieille que DirectX, mais sa conception robuste et stable est encore et toujours d'actualité après 20 années d'existence.
J'ai écrit mon jeu en C++, qui est également encore et toujours d'actualité malgré son âge. Je masquais les fonctionnalités spécifiques à l'iPhone qui nécessitaient un code Objective-C avec les fonctions et variables de type C, et il me suffisait donc de réécrire ces fonctions pour le portage sur PC.
J'ai structuré mon projet manuellement pour me permettre de combiner les projets Xcode, les projets Visual Studio et les fichiers makefile dans une disposition commune. Il a fallu que je planifie et que j'étudie correctement la chose pour y arriver, mais cette méthode s'est avérée bien plus efficace qu'une simple copie de fichiers ci et là. J'ai personnalisé ma configuration makefile et elle détecte automatiquement tous les fichiers de mon projet. Mais pour Xcode et Visual Studio, j'ai construit manuellement un projet en glissant tous mes fichiers source simultanément dans les répertoires.
Je synchronise mes fichiers avec Subversion (SVN), qui est également pratique pour les sauvegardes. Plus spécifiquement, j'utilise TortoiseSVN sur Windows et SCPlugin sur Mac. Les deux s'intègrent directement à l'Explorateur (Windows) et au Finder (Mac), ce qui en facilite grandement l'utilisation.
Côté PC, j'ai utilisé SDL comme hôte API plutôt que d'écrire un code d'API Windows natif. J'ai écrit un code natif pour iPhone, mais tous les PC sont SDL. Cela fonctionne en plus sur Windows, Linux et Mac, et également sur certains appareils mobiles basés sur Linux (Nokia, Palm).
Mais même si j'ai utilisé plusieurs bibliothèques standards, j'ai tout de même écrit ma propre bibliothèque de wrappers en plus d'OpenGL et de SDL. Cela me permettra à long terme de porter le jeu sur des plates-formes autres que celles prises en charge, notamment DirectX sous Windows, Khronos OpenKode (l'alternative du groupe OpenGL à SDL), ou les API natives des consoles de jeux comme la PlayStation.
Enfin, le code du jeu lui-même fonctionne comme un module qui repose sur le code spécifique d'une plate-forme. Il est doté d'une fonction d'initialisation, d'une fonction intermédiaire (STEP) et d'une fonction de dessin (DRAW). Le code du jeu ne se soucie par de la taille ou de la forme de l'écran, et il dessine en fonction de ce qui lui est donné. Chaque image du jeu est un appel de « STEP » puis de « DRAW », mais si le jeu tourne de plus en plus lentement, la fonction « STEP » peut être appelée plusieurs fois pour rattraper le retard.
Q. Comment avez-vous géré les différences matérielles (résolution d'écran, écran tactile multipoint ou souris/clavier et accéléromètre) sur l'iPhone ?
Mike Kasprzak :
J'ai fait deux trois manipulations en ce qui concerne les résolutions d'écran.
J'ai tout d'abord conçu le jeu et l'interface de telle manière à ce qu'ils soient modulables. Cela signifie que je ne me suis pas fié aux coordonnées des pixels pour positionner les choses à l'écran. Cela peut sembler un peu compliqué, mais le secret est de choisir une résolution de référence et de la moduler en fonction de la résolution réelle. Donc, si votre résolution de référence est de 480 x 270 par exemple, vous pourriez l'augmenter 4 fois jusqu'à 1920 x 1080 (c.-à-d. 1080p HD).
Là où les choses peuvent sembler encore plus complexes, c'est que la modulation est entièrement réalisée avec du matériel graphique 3D et la texturation. Mon jeu Smiles est un jeu en 2D, mais il utilise le matériel graphique 3D de l'appareil sur lequel il est installé. Le « truc » est de ne pas utiliser la coordonnée « Z » et d'ignorer des fonctionnalités comme les tests de profondeur. Il y a un peu plus de calculs lorsqu'on travaille avec du matériel 3D, mais tout ce qui est au 3D est accéléré de nos jours. Si vous ne l'utilisez pas, cela revient à sous-utiliser les performances.
Ensuite, j'étais persuadé qu'il fallait que je crée mes graphiques à très haute résolution. Même si je visais au début le tout petit écran de l'iPhone (480 x 320), la résolution de mes graphiques originaux était suffisamment élevée que pour avoir une qualité HD 1080p (1920 x 1080). En fait, l'une des choses les plus intéressantes sont les calculs. Vous pouvez créer des graphiques de la taille d'un écran de smartphone (iPhone (480 x 320) et autres), puis la doubler pour 720p HD (netbooks, tablettes, écrans de téléphone ayant un plus grand espacement entre les pixels), et la doubler encore une fois pour 1080p HD (PS3, Xbox 360 et autres PC de jeu haut de gamme). En pratique, cela signifie commencer au sommet avec des graphiques 1080p, puis les réduire de moitié pour vos appareils 720p, et les réduire encore de moitié pour les smartphones de plus faible résolution. Vous pouvez également facilement automatiser ce processus de réduction de la résolution.
Avec des graphiques et une interface modulables, un autre problème fait surface : le rapport hauteur/largeur. C'est la résolution de référence dont nous avons parlé précédemment qui gère l'adaptation aux rapports hauteur/largeur. Il vous suffit de choisir ou de calculer un scalaire qui les adapte à l'écran. Cela peut éventuellement créer un espace vide sur les côtés ou en-dessous. Plutôt que d'utiliser des barres noires dans Smiles, j'ai résolu ce problème de deux façons différentes. J'ai tout d'abord créé un arrière-plan en mosaïque, et j'ai ensuite créé un arrière-plan de très grande taille.
Les effets « mosaïque » sont très simples et fort modulables. Il vous suffit d'ajouter une ou deux rangées de mosaïques pour remplir l'espace vide.
Pour ce qui est des grands arrière-plans, l'idée est de créer quelque chose qui est plus grand que l'écran. Il suffit généralement de doubler la largeur et la hauteur de votre écran de référence. L'arrière-plan en lui-même ne contient généralement rien d'important visuellement parlant, mais si les utilisateurs peuvent le voir, il semble être à sa place.
En ce qui concerne la technologie tactile multipoint, elle ne m'a posé aucun problème particulier. En règle générale, la technologie tactile multipoint est principalement utilisée pour les gestes : zoom pincé, rotation à deux doigts, et ainsi de suite. En dépit de toutes ces fioritures, la chose la plus courante que l'on fait avec un écran tactile, c'est justement de le toucher.
Ce qui a nécessité une certaine réflexion en termes de design, ce sont les différences entre une souris et un écran tactile. Si vous comparez les deux, ils indiquent tous les deux la position, mais seule la souris permet de pointer. Je m'explique : un écran tactile ne peut vous indiquer que l'endroit que vous touchez, et non la position de votre main. En revanche, le curseur d'une souris survole ce sur quoi vous voulez appuyer et n'attend qu'un clic pour passer à l'action. D'un point de vue du design, si votre jeu fonctionne avec les écrans à saisie tactile unique, alors il fonctionnera avec une souris.
En fait, il y a même un troisième type de saisie à prendre en compte : les tablettes à stylet et les Tablet PC. On ne voit généralement ces appareils qu'entre les mains de graphistes, mais une tablette à stylet offre le meilleur des deux mondes : le positionnement physique (le pointeur va là ou la pointe va) et le pointage.
Et si vous voulez vraiment vous y perdre, pensez aux appareils de pointage avec caméra tels que Nintendo Wiimote, Sony PlayStation Move, Eyetoy et Microsoft Natal. Les deux premiers fonctionnent comme une souris, alors que les deux derniers fonctionnent plutôt comme un écran tactile multipoint.
Tous sont toutefois des systèmes de pointage. Ils offrent chacun une façon de spécifier une position avec différents niveaux de précision et de facilité. Le plus simple reste l'écran tactile, à savoir des positions sans pointage. Si vous focalisez votre design là-dessus, vous trouverez généralement un moyen de le faire fonctionner sur n'importe quel autre pointeur.
L'absence de clavier sur les appareils mobiles m'a persuadé de concevoir un jeu fonctionnant entièrement avec un pointeur (écran tactile, souris). C'est également plus facile pour les utilisateurs occasionnels en procédant de cette façon. Il n'est pas nécessaire de lâcher votre souris. Il vous suffit simplement de cliquer.
De la même manière qu'un écran tactile multipoint est généralement utilisé pour les gestes, un accéléromètre est généralement utilisé pour détecter l'orientation (portrait ou paysage). Forcer le jeu à s'orienter dans un sens particulier est la solution communément utilisée sur un ordinateur. Toutefois, sur l’iPhone, j'ai finalement utilisé la rotation physique comme mécanique du jeu, et il a donc fallu que je trouve un moyen de le faire fonctionner sur des plates-formes sans accéléromètre. J'ai donc pour cela ajouté des boutons de rotation à l'interface,
et le jeu est maintenant prêt à fonctionner sur n'importe quelle plate-forme. :)
Q : Avez-vous eu des surprises durant le processus de portage ? Était-ce plus facile ou plus difficile que vous ne le pensiez ?
Mike Kasprzak :
Il n'y a pas eu de grandes surprises, mais lorsque la programmation des graphiques est devenue relativement sérieuse, je me suis rendu compte que le jeu de composants Intel GMA 950 était bien meilleur que ce qu'on ne m'avait laissé entendre. En comparaison avec le PowerVR MBX de l'iPhone original, le GMA est de loin supérieur et offre facilement un rendu de résolution deux fois supérieur sans utiliser l'intégralité des performances. J'utilise même un netbook plutôt qu'un ordinateur portable puisqu'il a la puissance nécessaire. Si je travaille sur un projet relativement urgent, alors je passe à mon PC doté d'un processus quadricœur. Je n'ai par contre pas toujours besoin d'autant de puissance. Je peux me promener à la maison ou m'installer à l'extérieur sans devoir trimbaler mon ancien ordinateur portable gonflé à bloc acheté pour remplacer mon ordinateur de bureau.
La surprise était donc de pouvoir effectuer le portage sur le système lui-même.
Q : Avez-vous perdu ou amélioré des fonctionnalités ?
Mike Kasprzak :
Le jeu est quasiment identique, mais pour respecter mon échéance, j'ai provisoirement supprimé quelques fonctionnalités (modes de jeu). Elles seront à nouveau présentes, elles et bien d'autres, lors de la prochaine mise à jour. C'était vraiment une question de temps et non un problème lié aux capacités du netbook.
La version netbook était également une sorte de nouveau départ pour moi. En effet, j'ai pu apporter des corrections et modifier le design en toute sécurité puisqu'il n'y avait aucun risque d'effacer des jeux ou des meilleurs scores enregistrés dans la version iPhone établie. Alors même si quelques modes de jeu avaient initialement été supprimés, de nombreuses autres choses avaient déjà été modifiées. C'est l'un des avantages de la création et du portage de vos propres designs. Si vous décidez de changer quelque chose ou d'essayer quelque chose de différent, vous pouvez le faire sur une nouvelle plate-forme. De toute évidence, vous devez éviter de faire quelque chose qui risque de ruiner votre jeu, mais porter un jeu sur une nouvelle plate-forme est une liberté très intéressante.
Q : Comment comparez-vous l'utilisation même du jeu entre les deux appareils ?
Mike Kasprzak :
Les différences sont minimes ! La mécanique de jeu qui se cache derrière Smiles fonctionne de manière optimale sur un écran tactile, mais elle fonctionne également extraordinairement bien avec une souris. C'est un autre aspect d'AppUp que je trouve très intéressant. Nous parlons aujourd'hui de netbooks, mais les fabricants créent également des ordinateurs MID et Slate avec le même matériel (Intel Atom). Habituellement, il ne serait pas possible de nous mettre en face des clients de ce marché, mais grâce à AppUp, nous sommes en position de les servir.
Q : Avez-vous fait appel au support technique d'Intel durant le processus ? Qu'avez-vous pensé du processus de soumission et du support d'AppUp par rapport à ceux de l'iPhone ?
Mike Kasprzak :
Le processus de soumission était très facile. Je n'ai rencontré aucun problème en soi, mais Intel a répondu à toutes mes questions d'une manière admirable et opportune. Chaque plate-forme présente des nuances au niveau de la soumission, et c'est pourquoi on parle bien de soumission et non simplement de placer un téléchargement en ligne. AppUp est sans aucun doute l'un des systèmes les plus faciles.
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 leurs applications iPhone sur AppUp ?
Mike Kasprzak :
Je leur conseillerais principalement de penser en termes de portage dès le début. J'ai certainement beaucoup de choses à dire à ce sujet, mais le processus en soi n'est pas trop difficile à comprendre. Programmez votre jeu en C/C++, envisagez d'utiliser OpenGL ES et créez des graphiques haute résolution dès le début. Vous pourrez ainsi porter le code et les ressources de votre jeu où vous voulez. Incorporez-les dans SDL par exemple, et en un ou deux jours vous serez prêt à travailler sur un PC.