Mettre à l'échelle Scritchy Scratchy sur différentes plateformes

Apporter Scritchy Scratchy sur PC et mobile tout en le préparant pour Nintendo Switchᵀᴹ 2 et Nintendo Switch signifiait adapter une interaction tactile sur des appareils très différents.

Fournir cette même réactivité avec un contrôleur a obligé l'équipe à repenser l'entrée, le comportement de l'interface utilisateur, l'haptique et la manière dont le jeu s'adapte aux différentes tailles d'écran et aux ratios d'aspect.

Le processus de portage signifiait également équilibrer la performance avec la maintenabilité. Plutôt que de créer des branches de plateforme séparées, l'équipe a gardé le jeu dans un seul projet Unity afin que les optimisations, les corrections de bugs et le nouveau contenu puissent être transférés sur les différentes plateformes.

Depuis son lancement, le jeu a vendu plus de 1,25 million d'exemplaires sur Steam et 250 000 exemplaires sur mobile, tout en obtenant une note positive de 94 % sur Steam à travers plus de 14 000 critiques.

Nous avons parlé avec Constantin Lervig, directeur créatif chez Lunch Money Games ; Hannibal Sigfusson, PDG de Lunch Money Games ; Christian Biskopstø Thomsen, un programmeur travaillant avec Funday Games sur les versions mobiles et Nintendo Switch ; et Emil Kjæhr, responsable des produits et des partenaires chez Funday Games, des plus grands défis de portage de Scritchy Scratchy.

*Nintendo Switch est une marque déposée de Nintendo.

Quels ont été les plus grands défis techniques auxquels vous avez été confronté lors du portage?

TCC Les plus grands défis mobiles étaient les parties spécifiques à la plateforme : faire fonctionner correctement les versions pour l'App Store et google play, gérer les certificats, intégrer les SDK de plateforme et gérer des systèmes tels que les sauvegardes cloud.

L'entrée est devenue l'un des plus grands défis parce que nous avons conçu le jeu autour de la souris et du toucher. Nous devions décider comment le *scratching* devait fonctionner avec une manette de jeu. Cela a impliqué des discussions de conception et plusieurs itérations avant que nous ne trouvions quelque chose qui nous semblait juste.

Emil Kjæhr: Nous avons défini comment l'interaction devrait fonctionner, y compris l'alignement de l'entrée vers la zone pertinente lorsque vous ouvrez un ticket et commencez à gratter.

Pour la Nintendo Switch 2 spécifiquement, nous voulions également prendre en charge sa fonctionnalité de souris.

Sur mobile, nous avons ajouté un retour haptique lors du grattage. L'haptique se comporte différemment sur une vaste gamme d'appareils, en particulier sur Android. Nous avons eu des cas où les utilisateurs signalaient que leurs téléphones vibraient beaucoup trop fort, donc cela a nécessité quelques itérations.

Y avait-il des défis particuliers pour rendre les interactions de base tactiles sur toutes les plateformes?

TCC Le manette de jeu a été sans aucun doute l'interaction la plus difficile à traduire. Au toucher, le mécanisme de grattage a très bien fonctionné presque immédiatement. Avec un contrôleur, nous avons dû repenser comment cette même action devait se ressentir plutôt que de simplement mapper un curseur un à un.

EK: Nous quatre nous sommes assis pour un atelier et avons regardé directement la version PC. Nous avons efficacement décomposé l'interaction et la reconstruit sous forme de maquette filaire pour les autres plateformes.

Une fois que nous avons fait cela, l'approche intuitive est devenue assez claire. Cela témoigne également de la manière approfondie dont nous avons réfléchi à la conception originale d'un point de vue multiplateforme. Cela nous a fait gagner beaucoup de temps lorsque nous avons lancé le jeu sur mobile et que nous avons ensuite commencé à adapter l'interaction pour les manettes.

Quelle stratégie de portage avez-vous utilisée – une seule construction adaptée par plateforme, ou des branches séparées spécifiques à la plateforme ? Pourquoi?

TCC Nous avons choisi un seul projet et une seule base de code Unity plutôt que de maintenir des branches séparées de longue durée pour chaque plateforme.

Les branches de plateformes séparées ont tendance à diverger. Vous réglez quelque chose sur une branche, puis vous devez l'intégrer dans les autres. Une fois que vous soutenez quatre cibles ou plus, cela devient très vite fastidieux.

Un seul projet a son propre inconvénient parce que vous vous retrouvez avec une compilation conditionnelle et des vérifications spécifiques à la plateforme dans tout le code. Mais en raison de la taille et de la complexité de Scritchy Scratchy, nous l'avons maintenu à un niveau gérable.

CL: L'autre grand avantage d'un seul projet est que chaque petite optimisation et correction de bogue s'applique à toutes les versions.

Comment le Unity Profiler vous a-t-il aidé à trouver et à corriger les goulots d'étranglement spécifiques à la plateforme?

TCC J'ai beaucoup utilisé le Profiler Unity en travaillant sur les performances. Mon flux de travail est essentiellement : profiler d'abord, voir ce qui est réellement lent, puis corriger cela plutôt que de deviner.

Le plus grand exemple était les particules de rayure. Lorsque vous grattez un ticket, nous prenons des informations de la texture et générons des particules qui correspondent à la couleur de ce que vous grattez. Cela a très bien fonctionné sur PC, mais l'approche originale était trop lourde sur mobile.

La solution était d'utiliser instanciation GPU pour ces particules. Une fois que nous avons effectué ce changement, il est devenu l'une des optimisations de performance les plus importantes du port.

Comment le Input System vous a-t-il aidé à prendre en charge différents schémas de contrôle?

TCC Le fait que le tactile ait fonctionné presque entièrement dès la sortie de la boîte avec l'Input System a été extrêmement utile et a fait gagner beaucoup de temps.

Je peux brancher un contrôleur sur mon PC, jouer et tester les commandes directement dans l'Éditeur, puis construire le jeu pour Nintendo Switch. Les mappages de contrôleur sont conservés via l'Input System, ce qui accélère grandement l'itération.

HS: Dès le début du projet, nous avons construit une couche entre l'Input System et le reste de notre code. Le code du jeu n'a pas besoin de se soucier directement de chaque type d'entrée matérielle. Il peut utiliser cette couche pour déterminer si l'entrée a activé le pointeur, où se trouve le pointeur ou quelle est sa position dans le monde.

Quels objectifs de performance avez-vous fixés pour chaque plateforme, et à quel point les avez-vous atteints?

EK: Nous avons établi les niveaux minimums pris en charge pour les OS et les API sur mobile, puis nous avons testé sur des appareils proches de la limite inférieure de cette plage.

Une fois que nous avons implémenté le correctif d'instanciation GPU pour le système de particules, nous ne voyions plus de problèmes de fréquence d'images significatifs sur ces appareils.

Sur iOS, nous avons spécifiquement testé des appareils incluant l'iPhone X et l'iPhone XS pour nous assurer que le jeu fonctionnait bien sur le matériel que nous voulions prendre en charge. Nous avons suivi la même philosophie sur Android.

CL: Scritchy Scratchy doit sembler fluide parce que le grattage cesse d'être satisfaisant immédiatement si le jeu rame.

L'exigence était qu'il devait donner l'impression de gratter un ticket à gratter physique avec son doigt. En pratique, cela signifiait viser la fluidité que l'on obtient autour de 60 FPS.

TCC La résolution était un autre défi. Nous avons conçu le jeu original pour un écran PC grand écran. La plupart des résolutions de téléphone paysage se sont traduites de manière assez naturelle, mais le rapport d'aspect de l'iPad était plus difficile.

Nous avons eu assez de temps avant la sortie pour faire fonctionner la version iPad également. Cela impliquait d'ajuster la présentation et d'utiliser un certain zoom avant et arrière pour que la mise en page s'intègre naturellement.

L'objectif était que, peu importe si quelqu'un rencontrait Scritchy Scratchy en premier sur PC, un téléphone ou un iPad, cela donne l'impression qu'il appartient à cet appareil plutôt que d'être un port compromis.

Quelles décisions de Deployment ont fait la plus grande différence dans la qualité d'expédition entre les plateformes?

EK: La plus grande décision de Deployment était de tout garder dans un seul projet.

Cela est important non seulement pour le premier port, mais aussi pour la maintenabilité par la suite. Quand nous parlons de nouveau contenu arrivant dans le jeu, je n'ai pas à me soucier du temps qu'il faudra pour faire passer ce contenu à travers plusieurs branches de plateforme indépendantes.

CL: Cela a également facilité le déplacement des personnes entre les tâches. Nous avions un développeur qui nous aidait à corriger les bugs du PC et qui pouvait ensuite passer directement à la correction des problèmes mobiles sans avoir à apprendre une base de code mobile séparée.

Quel est votre meilleur conseil pour les développeurs qui prévoient de porter un jeu sur plusieurs plateformes?

CL: D'un point de vue de la conception, décidez tôt sur quelles plateformes le jeu pourrait potentiellement se trouver. Nous avons fait un choix précoce de ne pas nous concentrer fortement sur la manette de jeu, et nous avons vu plus tard comment cela a créé un travail supplémentaire.

HS: Pensez à l'entrée, à la résolution, aux ratios d'aspect et à la manière dont le jeu doit se sentir sur différentes plateformes dès le début. Ces choses sont beaucoup plus difficiles à ajouter plus tard.

Scritchy Scratchy est disponible sur Steam, l'App Store, et sur google play. Consultez plus d'histoires de développeurs Unity sur le Blog Unity et le Resource Hub.